Any reason to not just use a function? (like np.dot etc)
My understanding is that in python '*' means elementwise multiplication, so
even if you could monkeypatch numpys __mul__ method to do the right thing
wouldn't you be changing the semantics?
Gabriel
On Friday, October 7, 2016 at 3:51:11
t; organized than the Julia ecosystem. Insofar as it's getting better, it's
> because the community has agreed to make Hadley Wickham their benevolent
> dictator.
>
> --John
>
> On Friday, October 7, 2016 at 8:35:46 AM UTC-7, Gabriel Gellner wrote:
>>
>> Something th
Something that I have been noticing, as I convert more of my research code
over to Julia, is how the super easy to use package manager (which I love),
coupled with the talent base of the Julia community seems to have a
detrimental effect on the API consistency of the many “micro” packages
On Thursday, August 18, 2016 at 10:52:42 AM UTC-7, Michael Borregaard wrote:
>
> That sounds right. I wonder if this is not a bug?
>
>From my reading of the all the related issues, it is a known "issue" ;) It
looks like a good solution is being ironed out. But I don't think this will
be added
My understanding (which can easily be wrong!) is that this stems from
https://github.com/JuliaLang/julia/issues/16966.
Namely that size("b") throws a method error, whereas your size(2) gives a
null tuple (). So in general broadcast (which is what the .() is sugar for)
requires that the element
Can you just cast the array to Float64 or whatever numeric type you need to
column to be?
On Thursday, July 21, 2016 at 9:50:14 AM UTC-7, Ping Hou wrote:
>
> Hi,
>
> I encountered a problem when I running my code.
>
> LoadError: MethodError: `abs` has no method matching abs(::Array{Any,1})
>
Yay! thanks so much. Under my nose the whole time.
On Wednesday, July 20, 2016 at 4:30:44 PM UTC-7, Tim Holy wrote:
>
> On Wednesday, July 20, 2016 4:01:00 PM CDT Gabriel Gellner wrote:
> > Is there a standard (Base or common package) that implements something
> akin
> > t
Is there a standard (Base or common package) that implements something akin
to matlab's `findpeaks`. It is easy enough to make something like this, but
I imagined that this would be something that already exists but that I have
just missed?
I use the following as a utility to have PyPlot.jl/PyCall.jl automatically
convert RGB types into tuples
function PyObject(t::Color)
trgb = convert(RGB, t)
ctup = map(float, (red(trgb), green(trgb), blue(trgb)))
o = PyObject(ctup)
return o
end
I'm sure it can be tweaked to be
commit button now it's there
>
> Le 30/06/2016 20:52, Gabriel Gellner a écrit :
>
> You could also just make a repo on GitHub.
> See for example:
> https://github.com/dpsanders/intermediate_julia
>
>
> On Thursday, June 30, 2016 at 8:28:25 AM UTC-7, Henri Girard wrote:
You could also just make a repo on GitHub.
See for example:
https://github.com/dpsanders/intermediate_julia
On Thursday, June 30, 2016 at 8:28:25 AM UTC-7, Henri Girard wrote:
>
> I have done some examples in julia (in french) and I think it could be
> interesting for beginners. Juliabox or
Really good point about dispatch. Man need to think this through. Might
just be my brain not fully getting multiple dispatch versus OO inheritance
for this kind of design.
On Friday, June 24, 2016 at 12:29:48 PM UTC-7, Toivo Henningsson wrote:
>
> If you call the function Bar, then users might
Are there benefits to using this over atom? Why are people moving over?
Pros, Cons?
On Tuesday, June 21, 2016 at 3:26:52 PM UTC-7, David Anthoff wrote:
>
> Hi all,
>
>
>
> I’ve created a new github repo for a VS code extension
> https://github.com/davidanthoff/julia-vscode and it is published
For future conferences I would be super stoked to pay some fee to have
early access if that would help at all. Super stoked to see so many of
these sweet talks!
On Wednesday, June 22, 2016 at 6:49:43 AM UTC-7, Viral Shah wrote:
>
> Yes they will be and hopefully much sooner than last year.
>
>
name as the type, but I
guess I am thinking about this as a kind of specialized type of Foo, hence
the uppercase, but should I instead do
bar(...)
when I am returning these kind of specialized versions of Foo?
On Tuesday, June 21, 2016 at 11:44:07 AM UTC-7, Gabriel Gellner wrote:
>
> So
So going deeper into using my own types, and coding style in julia.
Lets say I have the container type
type Foo
On Monday, June 20, 2016 at 7:10:15 AM UTC-7, Gabriel Gellner wrote:
>
> That was what I was feeling. That this was a legacy issue for lowercase
> type "constructo
Welcome by the way! I used to use Python a lot myself. Julia is great, but
it does require a fair amount of extra learning due to its youth. I hope
you get past the rocky start :)
```
using PyPlot
using PyCall
@pyimport scipy.integrate as integrate
function f(y, t)
if t < 25
return
This should also work with python2 if you have the packages installed (I
don't have a python 3 install on my machine and the import works).
On Monday, June 20, 2016 at 6:30:36 AM UTC-7, Henri Girard wrote:
>
> Answering : I try with python3 and everything works
>
> Le lundi 20 juin 2016 15:14:21
cut: `linspace` has history, so does
> `zeros`. So, for a new container type I'd use the constructor `FooBar`.
>
> On Sun, 2016-06-19 at 23:12, Gabriel Gellner <gabriel...@gmail.com
> > wrote:
> > I am currently making some container like types, so I am using the
&g
ll have this issue.
>
> That said, using the heuristic of "eltype(f(y0))" will do better than it
> currently does (it would catch the case where all inputs are an Int but one
> application makes things floats, which is probably the most common problem).
>
> On Monday, June 20,
ntered here, so users will need to learn
> about it pretty quick or else they will see lots of other
> functions/packages break.
>
> On Monday, June 20, 2016 at 2:07:30 AM UTC+1, Gabriel Gellner wrote:
>>
>> Is this truly a type instability?
>>
>> The fun
I am currently making some container like types, so I am using the
convention of studly caps for the types ie `FooBar`. For usage I am
confused on what the julian convention is for having expressive type
constructors like for `Dict` and `DataFrame`, versus using methods like
`linspace`.
You are passing in the initial condition `start` as an integer, but ode23
needs this to be a float. Change it to `const start = 3.0` and you are
golden. This does feel like a bug you should file an issue at the github
page.
On Sunday, June 19, 2016 at 11:49:55 AM UTC-7, Joungmin Lee wrote:
>
>
What integration library are you using with Cython/Fortran? Is it using the
same algorithm as quadgk? Your code seems so simple I imagine this is just
comparing the quadrature implementations :)
On Saturday, June 18, 2016 at 5:53:57 AM UTC-7, Marius Millea wrote:
>
> Hi all, I'm sort of just
ke something that
> PyCall should maybe do since they are pretty much equivalent. Maybe open an
> issue here: https://github.com/stevengj/PyCall.jl?
>
> On Fri, Jun 17, 2016 at 3:58 PM, Gabriel Gellner <gabriel...@gmail.com
> > wrote:
>
>> Have you tried passing `:none
Have you tried passing `:none` in the argument list. I find that PyCall
does the correct conversion on the symbol.
On Friday, June 17, 2016 at 11:42:32 AM UTC-7, I Ce wrote:
>
> I am using PyCalland @pyimport cv2 to implement an OpenCV
> feature-matching program in Julia.
>
>
> I have an
I imagine you are using something like sympy that is doing a mathematica
like plot over omega (the var statements)
In which case you need to change the line
x = linspace(0, 2pi)
to
omega = linspace(0, 2*w) # which seems to be the true range from the python
code, not 2pi
and then you need to
Thank you so much for the feedback.
I just want to end with how much I love this community. I know this kind of
"bike shedding" discussion can be annoying. Especially with all the work
volunteers put in.
Also I love your work especially mauro :)
Anyway back to lurking.
Gabriel
I absolutely agree in general. I am terrified when julia code gets to fancy
:) I am largely a bear of little brain... (thos ODE.jl choice to send back
array of arrays kind of breaks this feeling for simplicity ... having to
learn to do hcat(sol...)' for the common case, versus letting this work
So much great news in this thread! I am crazy happy that ODE.jl is not
dead. As an interested outsider it seemed like the community got gridlocked
on the API discussion. It is nice that this is not the case.
A quick question as to why the matlab interface is better for small
problems, I don't
I think the name makes a tonne of sense given the scope, and fits in the
line with many standard packages: Calculus, Optim, Distributions, etc.
There is no reason that if a great Bifurcation suite grows it couldn't be
part of DifferentialEquations (though that feels weird to me personally).
sual for a situation to appear
> > where I would want one behavior for slicing and a different one for
> array
> > reduction. In situations where array dimensions correspond to, say,
> > repeated observations, it is common to compare slices to means or maxima
> > across dimensions
Does it bother you to do the A[[1], :] to keep the old behavior? I haven't
thought enough about the role of sum, mean etc.
On Wednesday, May 25, 2016 at 5:11:20 PM UTC-7, a. kramer wrote:
>
> Apologies in advance if this is something that has been discussed at
> length already, I wasn't able to
Perfect. I was hoping that this would be the solution. I am reading the
sections on getting this behavior more carefully. Thanks for the
clarification.
On Tuesday, May 24, 2016 at 2:04:22 PM UTC-7, Steven G. Johnson wrote:
>
>
>
> On Tuesday, May 24, 2016 at 3:01:12 PM UTC-4, Gab
I don't think those discussion points will make Siyi happy ;) We are
getting even more required use of dotted "broadcasting" instead of less
like he wants.
I much much prefer being explicit with the dots, but like all syntax
discussion it seems to get heated :)
On Tuesday, May 24, 2016 at
robably be changed later anyway.
>
> On Monday, May 23, 2016 at 2:50:34 AM UTC-4, Gabriel Gellner wrote:
>>
>> So I am not able to get such a dramatic speed up. Do you mean something
>> beyond:
>>
>> function linreg2{S <: Number, T <: Number}(x::AbstractArra
y. That will speed up the computation already now
> and with an unallocating cov, I see 20x speed up over linreg for n=1
> and Float64 element on 0.4.
>
> On Saturday, May 21, 2016 at 2:33:20 PM UTC-4, Gabriel Gellner wrote:
>>
>>
>>
>> I think it's an error. The me
On Sunday, May 22, 2016 at 8:37:43 PM UTC-7, Andreas Noack wrote:
>
> I don't think that linreg has received much attention over the years. Most
> often it is almost as simple to use \. It you take a look at linreg then
> I'd suggest that you try to write in terms of cov and var and return a
>
So I have a PR
https://github.com/JuliaLang/julia/pull/16523
I get an error on AppVeyor build which I don't understand. Any tips, or
missed documentation is greatly appreciated! My GitHub kung-fu is fledgling
at best.
On Saturday, May 21, 2016 at 11:33:20 AM UTC-7, Gabriel Gellner wrote
I think it's an error. The method definition should probably just be:
>
> linreg{T<:Number,S<:Number}(X::AbstractVector{T}, y::AbstractVector{S}) =
> [ones(T, size(X,1)) X] \ y
>
> which will allow it to work for X and y of different types.
>
> Is using the more specific typing (<: Number) the
Is it intentional that the builting linreg is so picky about its inputs? It
seems to me that the code is a one liner:
linreg{T<:Number}(X::AbstractVector{T}, y::AbstractVector{T}) = [ones(T,
size(X,1)) X] \ y
but forcing the types to be the same for both seems strange to me as it
throws errors
UTC-7, DNF wrote:
>
>
> On Tuesday, April 5, 2016 at 3:36:09 PM UTC+2, Gabriel Gellner wrote:
>>
>> you can do the python example as:
>>
>> a[[1, 4] + range(7, 17, 2)]
>> (ignoring the issues that this is not the same range as julia since
>> python
Sweetness. Thanks for the clarification!
On Tuesday, April 5, 2016 at 7:42:02 AM UTC-7, Cristóvão Duarte Sousa wrote:
>
>
> For the julia example isn't matlab like concatenation using ';' being
>> removed from julia?
>>
>
> No. Just the concatenation using ','
> (AFAIK)
>
>
you can do the python example as:
a[[1, 4] + range(7, 17, 2)]
(ignoring the issues that this is not the same range as julia since python
uses 0-based indices ...)
you don't need to index with an ndarray, and that way you can get the nice
use of the + operator for concatenate.
Lacking the :
As an end user that would love this, I would prefer a single package. Put
all them tasty, wacky colors in one place!
On Tuesday, 24 November 2015 14:08:35 UTC-8, Randy Zwitch wrote:
>
> Since the Julia ecosystem is getting bigger, I figured I'd propose this
> here first and see what people
Julia messes up the background colors in the windows console -- that is
-- it forces it to black. This boxed black background persists after julia
is exited. Is there somewhere to look for why this is happening? Or a fix?
Thanks so much.
Oh man ... please keep supporting anaconda. As a windows user being stuck
with easy_install haunts my dreams. Anaconda may be forkish, but at least
windows is a first class citizen. So many open source projects make using
Windows beyond painful.
On Monday, 2 November 2015 13:00:51 UTC-8,
If you use the C interface and not the simplified interface you can pass an
array of parameters to your lhs function. I found the best way to figure
out how is to look at the code for how they made the `cvode` function (in
Sundials.jl) to see how the C functions are being called and then look
I am trying my to figure out the Julian way to create a table of values
(matrix) from a function that returns multiple values. As this is really
thinking about the problem as a function that generates the rows of the
table it feels super awkward to do this in Julia currently. For example,
lets
in linspace(0, 10, 100)]
hcat(esol...)'
is this the idiomatic solution?
Is there a better way to do this? How do people generally deal with Array
or Arrays. Feels weird to me currently.
Gabriel
On Tuesday, 27 October 2015 09:31:22 UTC-7, Gabriel Gellner wrote:
>
> I am trying my to figu
t; mapreduce(exact,hcat,linspace(0,10,100))
>
> On Wednesday, 28 October 2015 02:38:56 UTC+10, Gabriel Gellner wrote:
>>
>> Okay sorry tab seems to send ...
>>
>> I am trying my to figure out the Julian way to create a table of values
>> (matrix) from a function
Seriously +9000 to this sentiment.
I am new to Julia but man what this community has made is incredible. The
beauty of this project staggers me. Not having to mess around with C for a
large chunk of my new codes inner loops feels like magic every time.
Thank you all so much.
Gabriel
On
On Monday, 26 October 2015 11:17:58 UTC-7, Christoph Ortner wrote:
>
> Fabian - Many thanks for your comments. This was very helpful.
>
> (c) if I want to write code now that shouldn't break with 0.5, what should
>> I do?
>>
>
> I think when you need a copy, just surround your getindex with a
On Sunday, 25 October 2015 07:05:03 UTC-7, Christoph Ortner wrote:
>
>
> very nice example - thank you - but I notice that you use linrange :).
>
> Thanks, Christoph
>
Man I wish they had called it linrange ;) with type LinRange. Still I am at
peace with the new way it works. Hopefully it will
On Sunday, 25 October 2015 11:06:14 UTC-7, Stefan Karpinski wrote:
>
> This is still an option but I'm yet to be convinced that we want to have
> that many things exported: linrange, LinRange, and linspace which just does
> collect on linrange? Seems like one too many.
Personally I think
>
> A related discussion is about a special Ones type representing an array
> of 1, which would allow efficient generic implementations of
> (non-)weighted statistical functions:
> https://github.com/JuliaStats/StatsBase.jl/issues/135
>
> But regarding zeros(), there might not be any
temp[1,2:end] = pi/(N0+1)*(1:N0)'
> temp[1,1] = phi_N
> h = E0/sqrt(2*N0+1)*exp(im*temp ) * coswt
> return h, tf;
> end
>
> On Wednesday, October 21, 2015 at 3:11:44 AM UTC-4, Gabriel Gellner wrote:
>>
>> I find the way that you need to use `linspace` an
I agree with this downvote so much it hurts. The logspace/linspace is
painfully ugly. linrange is the right name in my find for the iterator
version.
On Wednesday, 30 September 2015 10:31:55 UTC-7, Alex Ames wrote:
>
> Another downvote on linspace returning a range object. It seems odd for
>
Oh man thanks for this link. Makes me feel better that I am not alone in
feeling this pain. This is really the first *wart* I have felt in the
language decisions in Julia. Forcing iterators as the default such a common
array generation object feels so needless. Calling any code that asks for a
at 11:38 AM, Gabriel Gellner wrote:
>
> No that is a good point. Often you can use an iterator where an explicit
> array would also work. The issue I guess is that this puts the burden on
> the developer to always write generic code that when you would want to
> accept an Array yo
ke generic types? This would explain the linspace vs logspace and all
other basic array creating functions (ones, zeros, rand etc) and the
default names for many types vs the "Abstract" prefixed ones.
Thanks for all the insight.
On Wednesday, 21 October 2015 00:11:44 UTC-7, Gabriel Gelln
n the language (as in Matlab and Numpy).
>
> On Oct 21, 2015, at 2:38 PM, Gabriel Gellner <gabriel...@gmail.com
> > wrote:
>
> Wow! Thanks everyone for all the advice!!! Super helpful. I now see that
> it is super easy to deal with the LinSpace objects.
>
> That bei
and() is simply
> Impossible.
>
> On Wednesday, October 21, 2015 at 9:38:07 PM UTC+2, Gabriel Gellner wrote:
>>
>> I have no issue with the LinSpace object, I simply do not see why it is
>> the special case for this kind of object (I imagine the choice was made
>>
} parameters?
thanks
On Wednesday, 21 October 2015 14:25:17 UTC-7, Stefan Karpinski wrote:
>
> On Wed, Oct 21, 2015 at 5:13 PM, Gabriel Gellner <gabriel...@gmail.com
> > wrote:
>
>> Maybe all this is just transitional that soon LinSpace objects will
>> always work l
Sweetness. Thank you. AbstractArray it is for me!
On Wednesday, 21 October 2015 16:29:28 UTC-7, Tim Holy wrote:
>
> On Wednesday, October 21, 2015 03:32:04 PM Gabriel Gellner wrote:
> > * I can't use LinSpace in matrix mult A * b::LinSpace, is this simply a
> > Bug/Missing
the space was generated by linspace or logspace. But is that
>> really leading to 'madness'?
>>
>> There are other examples of these light-weight wrapper types being used,
>> especially in the linear algebra routines. The matrix factorization
>> functions, like qrf
I find the way that you need to use `linspace` and `range` objects a bit
jarring for when you want to write vectorized code, or when I want to pass
an array to a function that requires an Array. I get how nice the iterators
are when writing loops and that you can use `collect(iter)` to get a
67 matches
Mail list logo
