Is this truly a type instability? The function f has no type stability issues from my understanding of the concept. No matter the input types you always get a Float output so there is no type instability. Many of Julia's functions work this way, including division 1/2 -> float even though the inputs are ints.
The real issue is that ode23 infers the type of the output from y0 which in this case is an int, but I don't see how this is the correct inference. Maybe it is desired, but I hardly see this as normal Julia behavior. I can happily mix input types to arguments in many Julia constructs, without forcing me to have to use the same input vs output type. matrix mult, sin, sqrt, etc etc. Isn't this exactly what convert functions are for? hell the developer docs say that literals in expressions should be ints so that conversions can be better. that is they say I should right 2*x not 2.0*x so that type promotions can work correctly. The issue in this case is that an implementation detail is being exposed to the user, that eltype(y0) is determining the output of the function. I don't see that this is standard Julian practice, though it might be desired in this case. For example I can use quadgk(f, 1, 2) and not have an error because of the integer a, b. And that is a very similar style function Base method. Maybe I am missing something simple, but I worry being to harsh about types when it feels unessary. On Sunday, June 19, 2016 at 5:28:39 PM UTC-7, Chris Rackauckas wrote: > I wouldn't call this a bug, it's a standard Julia thing for a reason. You > get an InexactError() because you start with an Int and you do an operation > which turns the Int into a Float so the program gets mad at the type > instability. You can just change everything to floats, but then you're > getting rid of the user choice. For example, if you change everything to > floats, you can't solve it all using rationals of BigInts or whatever crazy > numbers the user wants. However, if you let the number operations do as > they normally do, the user can get an answer in the same way that they > provide it. And it's not like this is a weird thing inside some > mathematical packages, this is normal Julia behavior. > > But this kind of thing will cause issues for first-timers in Julia. It > should be front and center in the Noteworthy Differences from Other > Languages that if you really want a float, start with a float. > > On Sunday, June 19, 2016 at 10:06:42 PM UTC+1, Gabriel Gellner wrote: >> >> You are passing in the initial condition `start` as an integer, but ode23 >> needs this to be a float. Change it to `const start = 3.0` and you are >> golden. This does feel like a bug you should file an issue at the github >> page. >> >> On Sunday, June 19, 2016 at 11:49:55 AM UTC-7, Joungmin Lee wrote: >>> >>> Hi, >>> >>> I am making simple examples of the ODE package in Julia, but I cannot >>> make a code without error for 1st order ODE. >>> >>> Here is my code: >>> >>> using ODE; >>>> >>>> function f(t, y) >>>> x = y >>>> >>>> dx_dt = (2-x)/5 >>>> >>>> dx_dt >>>> end >>>> >>>> const start = 3; >>>> time = 0:0.1:30; >>>> >>>> t, y = ode23(f, start, time); >>>> >>> >>> It finally gives: >>> LoadError: InexactError() >>> while loading In[14], in expression starting on line 1 >>> >>> in copy! at abstractarray.jl:310 >>> in setindex! at array.jl:313 >>> in oderk_adapt at C:\Users\user\.julia\v0.4\ODE\src\runge_kutta.jl:279 >>> in oderk_adapt at C:\Users\user\.julia\v0.4\ODE\src\runge_kutta.jl:220 >>> in ode23 at C:\Users\user\.julia\v0.4\ODE\src\runge_kutta.jl:210 >>> >>> The example of 2nd order ODE at the GitHub works fine. >>> >>> How should I edit the code? >>> >>
