Thanks :)
On Tuesday, May 10, 2016 at 4:44:18 PM UTC+5:30, Lutfullah Tomak wrote:
>
> for (i,j)=zip(0:5,6:10)
> println(i+j)
> end
> On Tuesday, May 10, 2016 at 2:02:41 PM UTC+3, Vishnu Raj wrote:
>>
>> What if the equivalent of the C code below
>> for( i=0, j=6; i<=5, j <=10; i++, j++ )
for (i,j)=zip(0:5,6:10)
println(i+j)
end
On Tuesday, May 10, 2016 at 2:02:41 PM UTC+3, Vishnu Raj wrote:
>
> What if the equivalent of the C code below
> for( i=0, j=6; i<=5, j <=10; i++, j++ ) print( "%d", i+j );
> in julia?
>
Agreed with Tony. Having lots of ways to do the same thing is fine, as
long as we had no other syntactical use for the `=`. Anyone want to
support notation like: `for y = sin(_) in 1:10 ... end`? Probably not, so
no big deal to keep both around.
Also I just saw Tk's post with this great
+1
On Thursday, October 29, 2015 at 5:56:46 AM UTC-7, Tom Breloff wrote:
>
> Lets close the topic. Keep them both.
>
> On Thu, Oct 29, 2015 at 8:47 AM, feza
> wrote:
>
>> My only problem with `=` vs `in`
>> is that even the base julia code is inconsistent! Looking at one
1. Unless there is a single syntax, the topic will inevitably come up
again and again. This does not necessarily mean that we need a single
syntax, but this is a cost of the status quo (ie having both = and in)
that has to be considered.
2. I think everyone said what they wanted to say. IMO it
Maybe I was not clear: having multiple syntaxes per se is not
necessarily bad.
What is somewhat inconvenient is that since there is no good reason for
having multiple syntaxes, some newcomers to the language will be
confused, and will ask about this from time to time. Eg this is how this
thread
How is having multiple syntaxes for something automatically bad? I don't hear
people complaining that for loops are redundant when you could just do while
with a counter, or that enumerate is equivalent. Having style guidelines for
base to say when one choice makes more sense than another is
Well then it's settled. Someone prepare a PR ;)
But that's true of just about every instance where there are multiple ways
of doing things. vcat vs [;], for instance. In some cases, there are
distinct reasons; in others, there's no functional difference, and it only
exists for the purposes of making it easier to read, for instance. Like
My only problem with `=` vs `in`
is that even the base julia code is inconsistent! Looking at one file ( I
can't remember which now)
it had both
i = 1:nr
and
i in 1:n
Again this was in the same file! Please tell me I am not being pedantic
when I saw this and thought this must be fixed if even
Lets close the topic. Keep them both.
On Thu, Oct 29, 2015 at 8:47 AM, feza wrote:
> My only problem with `=` vs `in`
> is that even the base julia code is inconsistent! Looking at one file ( I
> can't remember which now)
> it had both
> i = 1:nr
> and
> i in 1:n
> Again
Hi,
Before closing (this thread?), I would like to write one more thing. First,
because I am not a native English speaker, it doesn't
actually matter how 1:n etc "reads" (simply because I don't pronounce them
in mind :) Second, when I started
learning Julia half a year ago (sorry for a slow
Do we want to give up on this topic? Then we should do so in an earnest way
and close the case with a clear message, ideally after
establishing if we want to add a style recommendation about the use of
``=`` and ``in`` to
http://docs.julialang.org/en/release-0.4/manual/style-guide/. Currently
> `=` better than `in`: `a = [ f(i,j,k) for i=1:p, j=1:q, k=1:r ]`
Please note that I am not trying to claim "=" is better universally (i.e.
for everyone) based on this example,
because some people prefer more English like syntax for clarity of meaning
(even when a bit longer).
So anyway, it
See https://github.com/JuliaLang/julia/issues/8487
On Wednesday, October 28, 2015 at 10:16:37 AM UTC-4, Stefan Karpinski wrote:
>
> No, it's just a matter of changing the parser to accept that – and
> convincing people that it's a good idea.
>
> On Wed, Oct 28, 2015 at 9:39 AM, DNF
I read 1:n that way. And even if I didn't, I prefer to think about a looping
construct as "do this for each element in that collection" - and regardless of
how I pronounce 1:n, I see it as a collection since it inherits AbstractArray.
But I can also see how other mental models work for you.
I'm with Tomas here - if anything this thread is testimony to the fact that
both '=' and 'in' should be left in.
I have to agree with Stefan that this is turning into
bikeshedding [1]. My personal bias is towards `in`, probably due to
my many years of Python, but I am convinced that both keeping the
current duality or picking one of them will not lead to a mental
overload. In fact, in order for us to stop
Pontus, you're awesome. Technically the first commit here was merged 4
minutes before your post, but funny anyway:
julia> mod(big"0xdfe0cc00e3ae91cd981d0b4243498f8321992fbc",10)
0
julia> mod(big"0xf8a4340548e7d6be31fede13cdc4e0f5f434f33f",10)
7
My opinion would be to leave it since Julia isn't
On Wednesday, October 28, 2015 at 9:51:10 AM UTC+1, Tamas Papp wrote:
>
> I am probably old-fashined, but I always prefer to stick to ASCII unless
> there is a compelling reason. If I want something to stick out, I can
> always customize Emacs to do it.
>
Well, both 'in' and '=' are ASCII,
I think people grossly exaggerate the "mental cost" of having both = and
in. It's really not that complicated, well explained in the docs and can
never cause bugs.
On the other hand the depreciation cost will big quite large, given it
seems both are used 50/50. Plus the numerous complain posts
On Wed, Oct 28 2015, feza wrote:
> But really this seems like a fundamental enough language construct that
> there should be only one correct way; but on the other hand my brain
> doesn't have a problem with `=` and it seems natural since I have been
> using matlab for a
You are right, of course. It's just one of those minor cosmetic things you
fix in a pre-1.0 version, or then maybe never. And it's good not to have
too many of those.
Also
for i ∈ 1:N
just looks incredibly awesome.
On Wednesday, October 28, 2015 at 1:38:57 PM UTC+1, STAR0SS wrote:
>
> I
On Wednesday, October 28, 2015 at 2:29:54 PM UTC+1, Stefan Karpinski wrote:
>
> I think we're getting into Parkinson's law territory here. First off, I
> don't think this causes all that much confusion. Second, since this is pure
> syntax involving a keyword no less, this is one of the easiest
actually its more about simple confusion rather than mental cost @DNF.
Starting out you either use = or in then you see some other code and they
use something else and wonder, what is right, is one notation faster or
better, what's going on? Of course, it's not the simplest thing to try and
I think we're getting into Parkinson's law territory here. First off, I
don't think this causes all that much confusion. Second, since this is pure
syntax involving a keyword no less, this is one of the easiest things to
mechanically fix should we chose to do so in the future.
On Wed, Oct 28,
On Wednesday, October 28, 2015 at 10:22:45 AM UTC+1, Glen O wrote:
>
> The thing is, it IS an assignment that's going on. In the case of a range,
> especially, "for i=1:5" says "loop 5 times, with i=1, then i=2, then i=3,
> then i=4, then i=5". "i' is being assigned to on each iteration. Think
No, it's just a matter of changing the parser to accept that – and
convincing people that it's a good idea.
On Wed, Oct 28, 2015 at 9:39 AM, DNF wrote:
> On Wednesday, October 28, 2015 at 2:29:54 PM UTC+1, Stefan Karpinski wrote:
>>
>> I think we're getting into Parkinson's
My vote is for keeping '='.
It is very readable for counters as is 'in' for other containers.
Confusion?
Considering the investment into learning all the new and powerful Julia
language constructs,
I don't see why exactly this elegant duality would be a problem for anyone.
It is not even a
On Wednesday, October 28, 2015 at 8:56:44 AM UTC+1, DNF wrote:
>
> I don't think = and in represent an elegant duality. They seem a very odd
> couple to me (even though I have been using = in Matlab for 15 years.) On
> the other hand, = and ∈ do seem to offer an elegant duality,
>
Sorry, of
On Wednesday, October 28, 2015 at 7:56:54 AM UTC+1, Gabor wrote:
>
> Confusion?
> Considering the investment into learning all the new and powerful Julia
> language constructs,
> I don't see why exactly this elegant duality would be a problem for anyone.
>
I don't think = and in represent an
On Wed, Oct 28 2015, DNF wrote:
> On Wednesday, October 28, 2015 at 7:56:54 AM UTC+1, Gabor wrote:
>>
>> Confusion?
>> Considering the investment into learning all the new and powerful Julia
>> language constructs,
>> I don't see why exactly this elegant duality would be a
The thing is, it IS an assignment that's going on. In the case of a range,
especially, "for i=1:5" says "loop 5 times, with i=1, then i=2, then i=3,
then i=4, then i=5". "i' is being assigned to on each iteration. Think of
it this way - suppose you were using elementwise operations. You could
Thank you. In that case I will happily stick with `in`.
On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>
> There is no difference, as far as I know.
>
> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems to
> be used more for variables (i in mylist). But
+1 @Tom Breloff .
I was confused about this when starting out. Comparing `for i in 1:3` vs
`for i = 1:3`, even though I regularly use matlab if you think about it
for `i = 1:10` doesn't really make a lot of sense. It would be nice if it
was just one way as opposed to the confusion about
An alternative way to read it is "for x equals 1 through 5". It definitely
makes sense for a range. And I don't think anyone has any difficulty
intuitively understanding a for loop using =, even if "in" reads slightly
better.
Incidentally, it's not just Matlab that does it. Most variants of
"When calculating a Fibonacci number, we have to apply F_n=F_(n-1)+F_(n-2)
repeatedly. So to find F_6, we apply the equation for n equals 3 through
6". Writing it as "for n in 3 through 6" or "for n in the range 3 through
6" wouldn't make nearly as much sense.
As I said, for general iterables,
>
> It definitely makes sense for a range.
Sorry... gotta disagree... mathematical set notation is more appropriate,
especially for scientific computing. This is coming from a former matlab
user, btw, so it's not like I was confused by the syntax. The "for i =
1:5" syntax is actually more
Please, leave the '=' alone. It's very well as is.
terça-feira, 27 de Outubro de 2015 às 18:20:19 UTC, FANG Colin escreveu:
>
> Julia tries to attract people from Python & R, which use `in`. As for
> matlab, it is not a direct competitor.
>
> Anyway, I think we only need 1 of the 2. "There
ent: Tuesday, October 27, 2015 11:20 AM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Re: For loop = or in?
Julia tries to attract people from Python & R, which use `in`. As for matlab,
it is not a direct competitor.
Anyway, I think we only need 1 of the 2. "There s
On Tuesday, October 27, 2015 at 4:56:12 PM UTC+1, Glen O wrote:
>
> Incidentally, it would be nice if ∈ could be used as another option - it's
> just another way of saying "in", but it would look nicer in certain
> mathematical contexts, and it's not like the symbol would be used in
> another
On Tue, Oct 27, 2015 at 10:04 AM, Stefan Karpinski
wrote:
> My general approach is to only use = when the RHS is an explicit range, as
> in `for i = 1:n`. For everything else I use `for i in v`. I would be ok
> with dropping the = syntax at some point, but it seems pretty
As far as I can understand, Julia also seems trying to attract people from
Matlab,
because there are so many similarities in the syntax (.* and ./ etc) and
the names of functions.
Also I often see questions from Matlab users posted in StackOverflow. Their
codes are
rather Matlab-like, but it
It's harmless, sure, but I would prefer that everyone uses "in" exclusively
so that there's one less thing to waste brainpower on. You don't say "for
each x equals the range 1 to n", you say "for each x in the range 1 to n".
I don't think "=" has a place here at all except to allow copy/pasting
My general approach is to only use = when the RHS is an explicit range, as
in `for i = 1:n`. For everything else I use `for i in v`. I would be ok
with dropping the = syntax at some point, but it seems pretty harmless to
have it.
On Tue, Oct 27, 2015 at 8:56 AM, FANG Colin
There is no difference, as far as I know.
'=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems to
be used more for variables (i in mylist). But using 'in' for everything is
ok too.
The '=' is there for familiarity with matlab. Remember that julia's syntax
was in part
How many worker threads did you start? Can you make D a SharedArray or
DArray?
On Sat Jan 31 2015 at 10:55:51 AM Paul Analyst paul.anal...@mail.com
wrote:
Realy ? Is imposibly smoething like :
take 1. column and copmute on 1. core, wihout waiting for end of 1.
oparation take 2. column and
Hi Paul,
If D is allocated on the master, then Julia will need to pass D from the
master to the workers. I'm guessing that this communication might be more
expensive than the compute in your loops. It may be useful to take a look
at distributed arrays in the parallel section of the Julia
Nash, big thx
julia procs()
1-element Array{Int64,1}:
1
julia addprocs(7)
7-element Array{Any,1}:
2
3
4
5
6
7
8
Now is 3-4 times faster !!!
Paul
W dniu 2015-01-31 o 17:00, Jameson Nash pisze:
How many worker threads did you start? Can you make D a SharedArray or
DArray?
On Sat Jan
Paul, until the threads branch gets merged, I recommend that you just accept
the fact that you'll only have 1 core active for most operations.
--Tim
On Saturday, January 31, 2015 07:15:25 AM paul analyst wrote:
Thx, but, no.
For sparse matrix 10^5,10^4,0.002 is the same . Time for both whiles
Thx, but, no.
For sparse matrix 10^5,10^4,0.002 is the same . Time for both whiles is
about 48 sek, only 11% o cores is used. I vave 8 cores, 7 sleeps:/
Paul
W dniu sobota, 31 stycznia 2015 15:50:02 UTC+1 użytkownik Sam Kaplan
napisał:
Hi Paul,
If D is allocated on the master, then Julia
Thanks for the tips! As an academic trying to move lots of code over from
other languages my lack of knowledge in coding fundamentals is being
exposed a bit.
Alex
On Sunday, September 7, 2014 3:03:01 PM UTC-7, Alex wrote:
Hi Everyone,
I've been having some trouble using a for loop to
EDIT: Sorry I forgot to add the output.
julia n=5
5
julia for i in [foo,bar]
x_$i=zeros(n,n)
println(x_$i)
end
x_foo
x_bar
julia x_foo
ERROR: x_foo not defined
On Sunday, September 7, 2014 3:03:01 PM UTC-7, Alex wrote:
Hi Everyone,
I've been having some
You’ll need to evaluate the type definition on all processes, using the
macro
@everywhere type parms
...
end
*after* adding the worker process. If I do that, I can run your code
without error. (However, k seems to be unchanged - you might have to use a
DArray (distributed array) in
Great, solve first problem, thanks.
using DArray though gives
julia k=DArray(parms,20)
exception on 2: ERROR: no method parms((UnitRange{Int64},))
in anonymous at multi.jl:840
in run_work_thunk at multi.jl:613
in run_work_thunk at multi.jl:622
in anonymous at task.jl:6
ERROR: assertion
also this works but does not change values in b
@parallel for i=1:20 b[i]=k[i].r*k[i].K end
I tried making b=DArray{Float64,1} or b=dones(20,1) but still values in b
are not updated
do I need to use spawn/fetch or pmap or something like this?
Sorry, not fluent in parallel programming yet, but
pmap is probably useful here.
Just to make sure, you *have* read the manual section on parallel
programming http://docs.julialang.org/en/latest/manual/parallel-computing/,
right? There's a lot of good stuff there =)
//T
On Tuesday, June 17, 2014 1:30:36 PM UTC+2, Jon Norberg wrote:
also
57 matches
Mail list logo