In principle it should just be to write something like
odefun(...,points==:specified)
But I'm not sure how many (if any) of the solvers implements that part of
the API. There was a lot of interest and discussion at some point, but it
seem to have slowed down recently.
kl. 08:39:59 UTC+1
Hi Erno,
I am afraid that points=:specified is currently not supported by ODE.jl.
There is a PR for adding ode23s (stiff solver)
https://github.com/JuliaLang/ODE.jl/pull/47, which supports it. So if you
need/want it now you might try that fork. As Ivar says we are discussing
how
Amen to that!
Yes, exactly, I was imagining it as a sugar for `4 == 2+2 ? go_home() :
nothing`. I'm liking this more the more I think about it.
Amazingly, Julia passes all tests after adding `then` to the reserved words
list in julia-syntax.scm. Of course, it should probably be deprecated as
an identifier
On Friday, 21 March 2014 21:54:53 UTC+1, Stefan Karpinski wrote:
On the other hand, saying 4 == 2 + 2 or go home is perfectly reasonable
;-)
I like the and || trick - hadn't seen it before and it's quite neat that
it just happens to work due to the language design! *But* the || was
I like the idea of providing a nice syntax for one if statements but agree
with Job van der Zwan about one-liners that grow. That comment immediately
made me think of Apple's
gotofailhttp://news.cnet.com/8301-13579_3-57619510-37/apple-finally-fixes-gotofail-os-x-security-hole/bug.
Maybe the
I'm probably being stupid here but why not just:
i==1 ? do_stuff()
It seems natural to me given the syntax A ? B : C
Cheers,
Ethan
On the other hand, saying 4 == 2 + 2 or go home is perfectly reasonable
;-)
On Thu, Mar 20, 2014 at 6:47 PM, John Myles White
johnmyleswh...@gmail.comwrote:
To me, this actually explains why the i == 1 do_stuff() idiom feels so
unnatural: you'd never mix a declarative statement with an
I quickly acclimated to Stefan's idiom and now happily read and write
code containing it. That said, it did throw me for a loop when first
learning the language. I'm not too big of a fan of reserving another
keyword for an optional syntax… but I could perhaps support its inclusion
if it
I kind of like that idea, actually.
On Fri, Mar 21, 2014 at 5:10 PM, Matt Bauman mbau...@gmail.com wrote:
I quickly acclimated to Stefan's idiom and now happily read and write
code containing it. That said, it did throw me for a loop when first
learning the language. I'm not too big of a
On Sat, Mar 22, 2014 at 9:23 AM, Stefan Karpinski ste...@karpinski.org wrote:
I kind of like that idea, actually.
On Fri, Mar 21, 2014 at 5:10 PM, Matt Bauman mbau...@gmail.com wrote:
I quickly acclimated to Stefan's idiom and now happily read and write
code containing it. That said, it
What would return from the statement if it were false? nothing? Like if I
use it assigning a variable? I definitely see the attraction as a one liner
though.
-Jacob
On Mar 21, 2014 9:52 PM, Chris Foster chris...@gmail.com wrote:
On Sat, Mar 22, 2014 at 9:23 AM, Stefan Karpinski
Given the similarity in syntax, I'd expect it to behave the same as a
normal if ... end
On Sat, Mar 22, 2014 at 12:05 PM, Jacob Quinn quinn.jac...@gmail.com wrote:
What would return from the statement if it were false? nothing? Like if I
use it assigning a variable? I definitely see the
Hum, ok.
Although the short-circuit is more or less known among several programming
languages, I don't think it's that readable outside of an if.
Maybe after a while one starts to read that code as if then, but it's not
so straightforward to beginners reading someone else's code.
But the
On Thu, Mar 20, 2014 at 7:24 PM, Cristóvão Duarte Sousa
cris...@gmail.com wrote:
Although the short-circuit is more or less known among several programming
languages, I don't think it's that readable outside of an if.
Maybe after a while one starts to read that code as if then, but it's not
so
I would urge you to always put a semicolon after the condition; you'd be
surprised at how often part of the consequent is parsed as part of the
condition otherwise! It's quite brittle.
In fact, I think that semicolon or newline should be required after the if
condition for this reason.
It's
Toivo, thanks for the advice. Indeed I had the feeling of some brittleness
when not using the semicolon, but I hadn't had any trouble yet.
Chris, I like that or short-circuit usage, it sounds very funny in Perl :)
On Thu, Mar 20, 2014 at 10:40 AM, Toivo Henningsson toivo@gmail.comwrote:
I
Too bad there isn't a inverse if statement like:
do_stuff() if i == 1
The suffix `if` and `unless` is the reason I never managed to become literate
in Ruby. Maybe it is just a matter of time and experience, but I read code
lines from left to right, and my mental read buffer is not long enough to see
the `if` that someone hid at the end of the line.
I agree. I've never liked python's do_stuff() if i == 1. It's too
disconcerting to parse what's going on and then have to backtrack and think
about the condition that came afterwards. I've found the i == 1
do_stuff() has become really natural after only using it a few times.
-Jacob
On Thu, Mar
I'm not so sure about i == 1 do_stuff() being readable, but I think it's
better than do_stuff() if i==1. Every time I see i==1 do_stuff(), I have
to stop and reason about what it's doing, but at least it isn't tricky.
With either you can read it easily, or you see that something weird is
going
On Wednesday, March 19, 2014 11:33:57 AM UTC-4, Cristóvão Duarte Sousa
wrote:
Sometimes I see myself writing one line if-elses like `if x0 x=-x end`,
which I think is not very readable.
Of course, in this particular case you could just do x = abs(x), but a
typical style for one-line
22 matches
Mail list logo
