On Mon, 2016-06-20 at 10:32, Chris Rackauckas wrote:
> I agree rationals don't make sense in most cases (I did it once just for
> fun), but how would it work with other defined numbers as they come? Will
> the promotions "just work?"
No. It is the duty of the type-creator to embed their new type
I agree rationals don't make sense in most cases (I did it once just for
fun), but how would it work with other defined numbers as they come? Will
the promotions "just work?"
But as mentioned, applying f once and using the types from there would
catch most cases.
On Monday, June 20, 2016 at 9
I'd say this is a bug. `sin(5)` works, so `ode23(f, 0, [0,1])` should
work too by promoting `y0=0` and `tspan=[0,1]` to appropriate types.
Note that `eltype(tspan)` needs to be promoted to some kind of floating
point number; I don't think rationals make sense for
differential-equations. I pushed
Thank you all for the discussion!
I have recently moved from Python to Julia, so I didn't know that. :)
Joungmin
2016년 6월 20일 월요일 오전 3시 49분 55초 UTC+9, Joungmin Lee 님의 말:
> Hi,
>
> I am making simple examples of the ODE package in Julia, but I cannot make
> a code without error for 1st order OD
Fair enough. I guess if the urge is to support strangely generic code then
the inputs should never be expected to be promoted. But I just don't see
what you are describing as being a "standard" in Julia. ODE.jl and your
project maybe try to attain this level of genericity, but most of Base
seem
But I gave an example where the output type can change depending on the
chosen timespan (eltype(y0)==Rational{Int}), so "eltype(f(y0))" can really
only be what the time integration algorithm actually produces, which means
you have to just run it and see what happens. It becomes a type-stability
I will admit my understanding of type stability in a jit compiler is
shakey, but I don't see 0.5//2 as a type instability, rather it is a method
error (the issues is a float does not convert to an int, but having a int
become a float is a fair promotion, so I can't see why requiring y0 to be a
I mean, it's the same type instability that you get if you try things like
.5//2. Many Julia function work with ints that give a float, but not all
do. If any function doesn't work (like convert will always fail if you
somehow got a float but initialized an array to be similar(arrInt)), then
yo
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 i
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
getti
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:
>
>
11 matches
Mail list logo
