UndefVarError: N not defined

Hi! Upgraded Julia to 1.0.1 from 0.7. Don’t want to say nice worlds, that I have to put all this spaces between .* operators and that someone genius renamed linspace and repmat functions. I’m strong enough to change it in my project. But can you explain me this:

Screenshot%20from%202018-10-10%2010-45-29

1 Like

https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Local-Scope-1

Thanks. As I understand this is for better parallelism?

Not necessarily, the reasons are somewhat subtle. This comment https://github.com/JuliaLang/julia/pull/19324#issuecomment-356339747 and the next one are good explanations. There is also a whole discussion thread on possibly changing this behavior in future versions because your same question keeps popping again and again.

2 Likes

Thanks! may be there is reason for it, but imagine, once in a month you take hammer from your toolbox for a job related things. And when you take it, you spend an hour to find handle because some engineers decided to replace it for safety reason.

1 Like

It’s more like you accepted that a tool producer sent you a prototype they had (Julia v0.6.x) and they clearly labelled it a prototype. While using this prototype, the producer often asked for feedback. You might not have had issues with your hammer, but other people did. So they engaged with the company, and the company improved it according to their feedback. There was even an online, and open-for-all place where these discussions were posted. The company has now released a finished version of the hammer (though it might send out new version in the future if there are further improvements to be made). You’ve asked for a copy. You may have to go over the manual once again for some things.

Also, please don’t write

Please show a bit more respect towards the people who have spent much of their time to develop something that you’ve apparently thought was good enough that you’d use it for a project.

6 Likes

When developers don’t show respect to users, who spent many hours writing project on their language, why should I? I upgraded to newer version, waiting better performance. But now instead of actually working I spend working day to figure out, why my perfectly worked project is not working. Is “linspace” function takes so much place so I have to spend time to replace it to “range” which makes the same job?
And in most of times people do not need to define global and local variables in loops. But now I have to write it in every tiny loop, isn’t it annoying?

1 Like

Depends. When I’m out asking for help, I usually try to be nice to the person whose time I’m asking to be spent on solving my problem.

I don’t think it’s productive to take this any further. Hope you find the answers you need to fix your scripts.

4 Likes

@MMalakhov Julia was a 0.x software so stability was never promised prior to 1.0. It is annoying to have to change things but respect should exist between developers and users. Changing the language is not a sign of disrespect from the developers, they are trying to improve things as they see fit. Each change was made for a reason, it made sense at the time for the people who were there discussing it and making decisions. If you want to watch for all future decisions taken in the language and voice your concerns before the decision is made, you can follow the Github project and comment there on issues and PRs. But commenting respectfully is equally important over there, and if your points are not convincing the developers will still go with what they think is right.

Relevant: On Open Source

3 Likes

OK, sorry. I drank green tea, calmed down and want to apologize. I was frustrated that I need to calculate some interesting things, but have to spend day in new language documentation

5 Likes

If you use julia 0.7, it will tell you exactly which changes you need to make so that your code will then work on 1.0.

1 Like