1.0 annoyances and Matlab comparison

Internals & Design
122

I think this thread proves that one of the only two hard problems in CS is naming things :smiley:

2 Likes
123

I wasn’t sure that that was true, I think I remember being told that you couldn’t count on that (but that was around when it was v0.3!)

124

Then don’t take my word for it! You, or someone else here, might know better than me, I seriously don’t understand the gc code.

125

I think the best way is to have something in a try/finally block, unless you segfault, that is guaranteed to run before it exits the block.

126

Wouldn’t it be great if there was a function doing that automatically - say zeros(m,n)? :troll:

1 Like
127

Yeah, good this function exists then.

1 Like
128

Oh, I thought that was being deprecated (to my great chagrin)? That was the point of the joke.
https://github.com/JuliaLang/julia/issues/24444

1 Like
129

That was my impression too. At one point as I was working on updating my package for 0.7 I was seeing deprecations of zerosand I started replacing them with fill…

130

zeros(rand(2,2)) is deprecated. zeros(m,n) is not.

8 Likes
131

Thanks for the clarification!

132

Looking through the thread I wish to second @Seif_Shebl in regards to the comment about Plotting.
For someone from the Computer Vision domain, plotting and visualisation is a must and the current options are by far too unstable.

Another issue that was addressed in other threads, but not here, is the lack of a good debugger with breakpoints.
For me, and my colleagues, a breakpoint is probably the biggest issue with Julia now (aside from plotting). I know it is WIP - ASTInterpreter2 for once, maybe more, just wanted to add that once again.

Last, I can assume it won’t change, but the fact that a function can use variables that were not passed to it (and weren’t global or something “special”) is very dangerous. for example:

function test_1(v)
  println(a);
end

a = 4;
test_1(6);

output: 4

The fact “a” is known inside the function is a source to bugs for people coming from other languages.

133

I guess that depends on what language you are coming from. That function scope behavior you mention is the same in Python. Also, for plotting I like PyPlot because it’s the same backend/syntax as in Python and is very stable. I had similar concerns early on, but now that I’m used to the REPL workflow I greatly prefer it. It’s actually much easier to tweak plots and inspect results as I rarely need to restart the REPL. Last week I needed to go back and do something in Python, and was surprised and how clunky my former run-the-whole-file workflow now feels.

On an unrelated note, can someone explain to me what the difference is between zeros(A) and zero(A) where A is an Array? I’ve followed this discussion, read several github issues, and am not quite clear on what this change means. I’ve seen discussion of zero, fill, and Array{T}(uninitialized. My main use case is that I very frequently write code segments where I need to initialize an array before doing some calculations and I’d like to initialize with zeros rather than uninit because the syntax is shorter and sometimes some of the values will remain zero. I use this code with both floats and dual numbers (for automatic differentiation) and so I need A to initialize with the right type. I’m going to overwrite most values, but the calculations are complex enough (generally many lines and maybe some if/else statements) that I can’t use a comprehension. Is the change I should be making just from zeros(A) to zero(A)?

134

There is a very slight and subtle difference between the additive identity of the matrix as a whole (zero(A)) and an array filled with the additive identity for its elements (zeros(A)), but I’m having a hard time imagining a case where they’d be different. To be pedantic: If you largely treat the matrix as an object in its own right, use zero(A). If you’re dealing more with the elements in the array, you can use zeros(eltype(A), size(A)).

2 Likes
135

I was not aware of that @andrewning, my experience is Cpp and Matlab, not Python.
Since the behaviour is different to Cpp and Matlab, I’m not convinced it was the best option to use the Python style in this case.

136

This is pretty fundamental to the language IIRC since a named function is just a global variable in a module.

2 Likes
137

@ChrisRackauckas - which is why I don’t really expect it to be modified anytime soon. but one can hope

138

I don’t really see how else it could work unless you want to declare every function you use before using it. I suspect that would not be popular.

3 Likes
139

var a is a global though? It’s not defined before the function, but the JIT runs when test_1 is first called?
It will also pick up a global defined after the first call here on v0.6.2

function test_1(v)
  local a;
  println(a);
  end;

a = 4;
test_1(6);
> Undef var error

function test_2(v)
  local a;
  println(b);
  end;

test_2(6);
> Undef var error
b = 3;
test_2(6);
> 3
140

For protection I would use a module:

module m
function test_1(v)
  local a;
  println(a);
end;

function test_2(v)
  local a;
  println(b);
end;
end
using .m
  
# Neither of these will be successful: all will error with "undefined variable"
# a = 4;
# m.test_1(6);

# m.test_2(6);
# b = 3;
# m.test_2(6);
141

You know what else are globals? Function names. They’re also not explicitly passed, and get picked up from the global environment. That’s why Stefan’s comment is so relevant.

4 Likes