That’s a strong statement, we mean for ODEs? If so, please provide such example and I am sure this will be resolved.

Oh, I think I didn’t write down my thoughts correctly. I only meant that I believe that Julia should be at par with MATLAB (or somewhere near), not that I know of some cases where it is not.

I do not read the statement as complaning but rather asking. Something like “I feel like switching fully to Julia but I worry if the accuracy of solvers for ODEs is as good as in Matlab. If yes, I will switch fully”.

Exactly, zdenek.

It is OK to complain! It can show bugs and that is very useful.

Regarding Julia’s speed and accuracy for ODEs, Chris compares Julia’s solvers with solvers from other languages (including Matlab) here: ODE Solver Multi-Language Wrapper Package Work-Precision Benchmarks (MATLAB, SciPy, Julia, deSolve (R))

…and a more-general comparison about the differential equation tools in several languages: A Comparison Between Differential Equation Solver Suites In MATLAB, R, Julia, Python, C, Mathematica, Maple, and Fortran - Stochastic Lifestyle

Welcome!

The *key* error you make is that indexing arrays in Julia is done using *square brackets*, i.e., you should use `y[i,1] = sin(2*i)`

. (I have also changed parenthesis arguments from `:,1`

to `i,1`

).

Next, in Julia, vector is a special data type, and there is no reason to make it into a column matrix. So it would be better to define `y`

as `y = zeros(11)`

, and insert values by `y[i] = sin(2*i)`

.

Julia’s DifferentialEquations suite has more efficient/modern high order rules than Matlab, as well as more specialized rules (such as adaptive SSP rules, high-order stochastic DEs, high-order delay DEs, etc.) so it should often be possible to get more accuracy with fewer function evaluations. See A Comparison Between Differential Equation Solver Suites In MATLAB, R, Julia, Python, C, Mathematica, Maple, and Fortran - Stochastic Lifestyle

Moreover, because your right-hand side function in Julia is compiled and fast (if it is written properly), even with the same number of function evaluations it is often vastly faster than Matlab (where performance is limited by the necessity of a user-code callback in the inner loop).

TY stillyslalom and stevengj.

So, finally this is how one would do it in Julia

```
for i in 1:1:11
j = (i-1)/10
y[i,1]=sin(2*j)
end
```

Like this:

```
for i in 1:11 #not 1:1:11
j = (i-1)/10 # no semicolon
y[i] = sin(2*j) # use a vector instead of a matrix
end
```

In Matlab, too, you should use `1:11`

, not `1:1:11`

.

Oops, that semi-colon was a hangover from MATLAB.

Blockquote In Matlab, too, you should use

`1:11`

, not`1:1:11`

So, does the former give better speed?

No, that won’t give you better speed. It’s just slightly more readable, maybe.

Probably not. It gives some more information to the compiler, but I doubt it matters. But it is more idiomatic.

Ok, but the perfectionist in me prefers the full form.

It is more correct imho to write `1:11`

. Why do you think this syntax exists? It’s actually the perfectionist in me that makes me point this out to you, when it’s really quite unimportant.

If you write 1:1:11, you are saying that a certain number of elements should be skipped. That number is zero, but it’s still a bit strange.

Would you write `1-1`

instead of `0`

?

I would perhaps only say that no one uses `1:1:11`

, and after getting a little bit more comfortable with the language that will not look quite natural. It feels like my insistence in indenting blocks with only two spaces… I am finally after a year of looking at others’ people code just finding four spaces more natural, and starting to follow the herd.

Blockquote It’s actually the perfectionist in me that makes me point this out to you, when it’s really quite unimportant.

It’s perfectly okay! I, too, like nitpicking

The reason why I prefer 1:1:10 over 1:10 is that the former is a general syntax (the increment may also be other than 1, like 0.5 or 2).

Yes, that’s exactly why `1:11`

is better. It says to take *all* elements in an interval instead of ‘skip zero elements in each jump’. It’s *because* it’s less general that it’s better, it structurally encodes that all elements must be included.

This is true for many intents and purposes, but not true in general, at least not on the latest release of julia

```
julia> 0 * (1:10)
ERROR: ArgumentError: step cannot be zero
```

For v1.7, this caveat has gone away

```
julia> 0 * (1:10)
StepRangeLen(0, 0, 10)
```