On Thu, May 1, 2014 at 11:49 PM, km srikrishnamo...@gmail.com wrote:
Yes I would say having one syntax is the best thing to do. This would be
less confusing. More the ways of doing it more confusing the code looks.
Too many symbols like {,},(,), decrease code readability. Which is why I
You could easily improve the latter one by helping the compiler with type
inference, though:
julia a
3-element Array{Number,1}:
1
2
3
julia reshape([ a[i]::Number for i=1:length(a) ], size(a))
3-element Array{Number,1}:
1
2
3
The reason this doesn't work well in the global scope is that
We talked at some point about making :R syntax for symbol(R) and
requiring something like :(R) to express the fairly useless operation
of quoting the string R (this is useless because the result is just the
string R). Barring some problem with this that I'm not thinking of, I'd
be in favor of such
:R for symbol(R) makes sense to me, so if it's not in the way of
anything else, I'm all for it.
And yeah, :R == R returns true, so I don't see how this could
really make something impossible to do, which is possible today. I guess if
there's code out that quotes literal strings like that it'll
Does your code break if it is applied to an array with an abstract element
type? If so, you must be doing something rather strange.
Stefan, I think this is stated too strongly. There have been many questions
and issues related to arrays with abstract element type. For functions
returning
But what's your suggestion about typed dict comprehensions?
On Thursday, May 1, 2014 7:11:59 PM UTC+2, Stefan Karpinski wrote:
Is be more in favor of deprecating the (K=V)[k=v] syntax and just using
keyword args like this Dict{K,V}(k=v). Having so many syntaxes for this is
confusing and
I have to admit that I am quite unhappy with some of the changed features in
Julia version 0.3.0, especially the 'dot' notation. Here are some examples.
Let x be a vector defined as x = [0.1, 0.2, 0.3] . Then typing
julia 5 + x
WARNING: x::Number + A::Array is deprecated, use x .+ A
I would discourage using R as the name of a column in a DataFrame.
Part of the reason we’re using symbols now is that it will encourage people to
use column names that are valid Julia variable names. If you stick to valid
variable names, you’ll always be able to use metaprogramming tools like
I'm still trying to settle into proper syntax and style, and all comments
are welcome!
For potentially longer if / elseif / else clauses, e.g.
# an overly simplistic example
if ndims(wt) == 2
println(Matrix stuff)
elseif ndims(wt) == 1
println(Vector stuff)
else
I can't answer for the max/maximum case, but regarding dot notation for
vector operations, it all quite makes sense if one tries to be as strict as
possible with using actual mathematical notation.
For example, having previously defined x = [0.1, 0.2, 0.3], then saying
x + 5
isn't really
but 5 + x is a universal mathematical notation that should be allowed
to be used regardless of any programming language considerations
Actually, it is the other way around. 5+x does not make sense
mathematically if x is a vector, but it is accepted in many programming
language as a
See also the discussion in https://github.com/JuliaLang/julia/pull/5810
and https://github.com/JuliaLang/julia/issues/5807 for the .+ vs + question.
The second argument to maximum is called region, and lets you compute the
maximum over a specific direction. The error checking seems to be non
See: https://github.com/JuliaLang/julia/issues/5410 for progress on a
possible switch statement
Also, I would probably recommend that you restructure your code so that you
can use multiple dispatch. Your example is overly simple, so it is hard to
tell you how to solve the problems that might
Hi Ted,
To the Bay Area Julia Meetup group: Do you think Forio would be open to the
idea?
We are certainly open to the idea. BAJU meetups are consistently drawing
around 50-70 registrations and 25 attendees ever few weeks. I am a bit
skeptical that a formally scheduled hack night would
On Friday, May 2, 2014, Cameron McBride cameron.mcbr...@gmail.com wrote:
I'm still trying to settle into proper syntax and style, and all comments
are welcome!
For potentially longer if / elseif / else clauses, e.g.
# an overly simplistic example
if ndims(wt) == 2
println(Matrix
Well, yes, I should have put a rather big asterisk on that:
* Unless your code explicitly depends on the element type of that or
derived arrays.
So, yes, it's not that simple.
On Fri, May 2, 2014 at 9:06 AM, Andreas Noack Jensen
andreasnoackjen...@gmail.com wrote:
Does your code break if it
What John said. This said, an old idea for the DF design would be to
include additional metadata for each column, which could include things
like an arbitrary Unicode pretty name that's not restricted to valid
variable name strings.
On Fri, May 2, 2014 at 10:08 AM, John Myles White
Also, at some point one may be able to write df.foo instead of df[:foo].
On Fri, May 2, 2014 at 11:21 AM, Harlan Harris har...@harris.name wrote:
What John said. This said, an old idea for the DF design would be to
include additional metadata for each column, which could include things
like
We are trying to develop a program to find the different roots of a nth
degree polynomial using a few quite simple methods (fixed-point, bisection,
newton..) and we would like to know how, when given a function, to
recognise it's degree in order to choose between different root-finding
Yeah, that I've got nothing for unless we did this:
(K,V)[ k = f(v) for (k,v) in d ]
On Fri, May 2, 2014 at 9:35 AM, Carlo Baldassi carlobalda...@gmail.comwrote:
But what's your suggestion about typed dict comprehensions?
On Thursday, May 1, 2014 7:11:59 PM UTC+2, Stefan Karpinski wrote:
There isn't a built-in polynomial type, but it's pretty easy to make one.
If the type of the polynomial depends on its degree, then you can dispatch
on it. For example, you could do something like this:
immutable Polynomial{n,T:Number}
a::NTuple{n,T}
end
Polynomial(a::Number...) =
Not if we took the {} syntax for empty dict, but this is becoming a rather
disruptive change.
On Fri, May 2, 2014 at 11:48 AM, Mike Nolta m...@nolta.net wrote:
But then it's unclear if (A,(B,C))[] is Dict{A,Dict{B,C}} or Dict{A,(B,C)}.
-Mike
On Fri, May 2, 2014 at 11:26 AM, Stefan
It took me a second to get used to .+ but now it feels very natural to me.
Maybe it helps to see the benefits (rather than just the changes). From my
perspective you gain functionality in that .+ has implicit broadcasting:
x = [1 2;
2 3]
row = [3 4]
x + row # this correctly gives an
Excellent. Thanks to both of you!
Cameron
On Fri, May 2, 2014 at 11:11 AM, Kevin Squire kevin.squ...@gmail.comwrote:
On Friday, May 2, 2014, Cameron McBride cameron.mcbr...@gmail.com wrote:
I'm still trying to settle into proper syntax and style, and all comments
are welcome!
For
Thank you everybody, almost every point discussed here is now written on my
blog http://stla.github.io/stlapblog/posts/KantorovichWithJulia.html.
Looks good!
On Friday, May 2, 2014 12:55:49 PM UTC-4, Stéphane Laurent wrote:
Thank you everybody, almost every point discussed here is now written on
my blog http://stla.github.io/stlapblog/posts/KantorovichWithJulia.html.
Okay, no problem, I'll get used to it.
I give Matlab courses and almost every year the 'dot' notation is one of
the most
difficult things for the students to learn and to remember in their
homework.
At one point I wondered myself what the .' operator is doing.
Is there something similar in
See also loladiro's Polynomials.jl package, which would accept pull
requests for alternative root finding methods to be added (there's an open
issue on my original fork to add a realroots function, at minimum)
On Friday, May 2, 2014, Stefan Karpinski ste...@karpinski.org wrote:
There isn't a
[1:3]' is the conjugate transpose of [1:3]
[1:3].' is the regular transpose
The difference is that the first apply conj() on all the elements while
transposing. This is confusing for everyone who does not live and breathe
complex linear algebra, but apparently very natural for those who do.
Thanks Stu! Just voted, but my only gripe is that if I vote to have it on a
weeknight, it seems to imply I won't make it on a weekend (and vice versa).
I just ask that you consider the voters who are open to both weeknights and
weekends depending on the circumstances when tallying up all the
We're happy to announce the release of JuMP 0.5, which includes support for
modeling and solving convex and nonconvex nonlinear optimization problems
which can be modeled by closed-form algebraic expressions. This extends
JuMP's existing support for linear, mixed-integer, and second-order conic
Very impressive work – the automatic differentiation is particularly cool.
On Fri, May 2, 2014 at 2:28 PM, Miles Lubin miles.lu...@gmail.com wrote:
We're happy to announce the release of JuMP 0.5, which includes support
for modeling and solving convex and nonconvex nonlinear optimization
On Tuesday, 29 April 2014 19:17:50 UTC+2, Hans W Borchers wrote:
[...]
As Arnold Neumaier once wrote on
I found CMA-ES quite robust in dimensions up to 50.
(It gets very slow though when the dimension is large.)
we can make this more specific: with n the search space dimension,
Trying to go over some questions on Project Euler, and I see that this
package https://github.com/JuliaLang/Iterators.jl would be very handy. I
might be wrong, but it seems as though it is in the standard library, since
its under Julialang/Iterators.jl.
My (failed) attempts so far:
*julia
Check out the chapter about packages:
http://docs.julialang.org/en/latest/manual/packages/
You need to install the package first.
Pkg.add(Iterators)
On Fri, May 2, 2014 at 5:34 PM, John Myles White
johnmyleswh...@gmail.comwrote:
Iterators isn't in Base. You need to install it through the
Great Idea. I live in Bangladesh, so I might be one in a handful of people
who're actually using Julia (or even playing around with it for that
matter). So, would anyone be interested in a hangout? I'd love to learn
more, because right now my skills aren't the best :(
On Tuesday, April 29,
Ahh much appreciated. My initial assumption was wrong it seems or perhaps I
was overthinking it.
Just out of curiosity, what *is* included in the stdlib?
On Saturday, May 3, 2014 3:34:45 AM UTC+6, Jacob Quinn wrote:
Check out the chapter about packages:
http://docs.julialang.org/en/latest/stdlib/base/
On Fri, May 2, 2014 at 5:41 PM, Nafiul Islam gamesbrain...@gmail.comwrote:
Ahh much appreciated. My initial assumption was wrong it seems or perhaps
I was overthinking it.
Just out of curiosity, what *is* included in the stdlib?
On
In another thread I mentioned looking at some largish data sets (10's of
gigabytes in the form of a .csv file). I have made some progress treating
the file as a memory-mapped Uint8 array but that hasn't been as effective
as I would have hoped. Using a shared array and multiple processes seems
Hi (again)!
Hopefully a (slightly) more intelligent question this time. I've been
successfully able to run shell commands from Julia through Base.run, and
the first thing I did was clear the screen:
julia Base.run(`clear`)
However, I wanted to ask, if there was an inbuilt function that does
There's no command, but ctrl-l (ctrl-ell) clears the screen.
Cheers, Kevin
On Fri, May 2, 2014 at 3:09 PM, Nafiul Islam gamesbrain...@gmail.comwrote:
Hi (again)!
Hopefully a (slightly) more intelligent question this time. I've been
successfully able to run shell commands from Julia through
I think the equivalent to Python's dir() command would be `names()`.
If you want to customize julia on startup, you can create a .juliarc.jl file
and that file will be included at startup.
There is also the shell mode in the REPL that allows you to type shell
commands directly. To get into on
The shell mode is a shortcut for Base.run(`clear`) where you just type ;clear
43 matches
Mail list logo