Lex,
I am fine not having the terse syntax of #1. In fact I am not asking why
f2() threw an exception. I was only worried why the syntax of f1() lays a
trap for me that I will fall in to later.
In other languages I am familiar with, finally is orthogonal to what
happens inside catch (or
On Wednesday, April 8, 2015 at 3:08:53 PM UTC+10, Toivo Henningsson wrote:
I think you are right that this is deliberate, but I also think that
making catch and finally orthogonal to each other should trump such case by
case optimizations. It would allow a simpler mental model of the
If we require a 'catch' block for every try, it would be cleaner.
Otherwise I suggest we had a note in the documentation to state the
caveats. Particularly for those who come from other background and get too
excited about try end terse syntax. I would be happy to make some edits
in the
just a moment to applaud this exemplary thread !!!
excellent closing post ...
love the Julia community.
best,
cdm
Recently, I am interested about the two functions enumerate(iter) and
zip(iter). So I read the iterator.jl and find they are realized by
different Types. I thought the enumerate was an alias like
zip([1:length(a)], a), however it is not.
I am curious that why the two functions are realized by
In a sense, a SharedArray should act like an Array if you're using a single
core. I'm not saying all methods have been implemented for them, but if the
code runs then it certainly shouldn't give different answers. So I'd say this
is a bug.
So now that we know it's a bug, I'd urge you to file
Thanks, Seth, that example looks even stranger than what I encountered.
I have suggested adding a short paragraph to the manual:
https://github.com/JuliaLang/julia/pull/10769
I can't think of a case where the author of code would like a default value
of a method to be used in another method
Excuse my ignorance Tim! I just don't allow myself to waste too much time
on this, so that I'm not looking into things very deeply.
This indeed solves the issue in a slightly different way.
I think we can definitely reuse more of what Images is currently doing.
It makes a lot of sense to switch
No criticism intended, I just wanted to save you (or anyone else) time :-).
I agree that it's also a great opportunity to refactor, and (without taking
the time to think about it too deeply) your suggestions seem very reasonable.
Best,
--Tim
On Wednesday, April 08, 2015 07:23:40 AM Simon
I understand *why* you're using them; the question is whether they're
broken or not. One way to figure that out is to not use them and see if you
still get the weird behavior.
(No worries on the response speed, this is your issue after all!)
On Wednesday, April 8, 2015 at 7:57:54 AM UTC-5,
I was a little surprised today by the following behaviour:
julia f(d=2) = d
f (generic function with 2 methods)
julia f(a::Int) = -a
f (generic function with 3 methods)
julia f()
-2
julia methods(f)
# 3 methods for generic function f:
f() at none:1
f(a::Int64) at none:1
f(d) at none:1
Yet,
Given the lack of replies, I'd guess that the answer is no. Searching
holt-winters julia jl didn't turn up anything.
Your options might be:
* Use RCall to call the function in R. RCall is still rather young.
* Use PyCall to call a function in Python. PyCall is fairly mature.
* Implement your
Images has (I think) basically already solved this problem. The way it uses
magic numbers is described at
https://github.com/timholy/Images.jl/blob/master/doc/extendingIO.md
For the example (a SIF) file, the magic bytes are enclosed in that
bAndor Technology Multi-Channel File
string.
--Tim
On
That is a bit surprising indeed. Maybe worth an addition to
http://docs.julialang.org/en/latest/manual/methods/#note-on-optional-and-keyword-arguments
?
It's not only surprising, I'd consider it (absent a real reason why it
should be this way) incorrect. Once you've decided which
That implementation has a few drawbacks: it allocates a vector of indices
the length of what it's iterating over; it has to know in advance how long
what it's iterating over is; it is more complicated, leading to more
complex machine code.
On Wed, Apr 8, 2015 at 4:51 AM, Jinxuan Zhu
This is half true.
Magic numbers are only used in ImageMagick.jl per accident, as that's how
the underlying C-library does things.
To be honest, I haven't looked at the details yet myself, as I mostly copy
and pasted code to get a first prototype running.
I sketch out in FileIO.jl#3
Hi Patrick,
Sorry for the late reply (Easter and all that)! The problem with using
Arrays in the code above is that they're not available for remote processes
to write on, so I'd have to come up with a more complicated structure of
passing computations and results around. The whole appeal of
On Wed, 2015-04-08 at 15:34, Daan Huybrechs daan.huybre...@gmail.com wrote:
I was a little surprised today by the following behaviour:
julia f(d=2) = d
f (generic function with 2 methods)
julia f(a::Int) = -a
f (generic function with 3 methods)
julia f()
-2
julia methods(f)
# 3
there is something to be said for the explicitness that comes with only
catching exceptions when there is a catch keyword involved.
Absolutely. Please go that way. It would be even better to make a catch
mandatory with each try, in order to ( as someone else here said ) ease
the load on
I come from a Python background where direct access to fields in for
example classes with the dot notation is very common.
However, from what I have seen in different conversations, accessing fields
directly is not really Julian. Sort of a fields are an implementation
detail mindset, and what
Thank you for the code and the pull request link. Very interesting.
On Tuesday, April 7, 2015 at 8:55:34 PM UTC+2, Mauro wrote:
In 0.3 it's not possible in 0.4 this works:
julia type A{T,P}
a::T
end
julia typealias B{T} A{T, 1}
A{T,1}
julia call{T}(::Type{B},
On Wednesday, April 8, 2015 at 3:52:44 PM UTC+2, Mauro wrote:
On Wed, 2015-04-08 at 15:34, Daan Huybrechs daan.hu...@gmail.com
javascript: wrote:
I was a little surprised today by the following behaviour:
julia f(d=2) = d
f (generic function with 2 methods)
julia f(a::Int) =
It's a matter of taste, really, but in general I agree that the Julian way is
to reduce the number of accesses to fields directly. That said, I do sometimes
access the fields.
However, your iterator example is a good opportunity to illustrate a more
julian approach:
mesh = mesh(...)
for
Apologies again for being a little slow (mentally now, not in terms of
response time); by trying an Array you mean running the code in single-core
mode and using an Array instead of a SharedArray? Running it in parallel
with a regular Array (unsurprisingly) doesn't work. So I have:
Single
Sounds like a bug, but I think what Patrick was trying to say is that it would
help to test it with Arrays first just to make sure there's not some problem
with your code. Assuming that it works for Arrays but not for SharedArrays,
then you should probably file an issue.
Best,
--Tim
On
Can you comment on the performance implications of directly accessing
fields vs your approach? I'm guessing that directly accessing the fields
would be faster?
I think usually it should get inlined and there is no difference:
julia immutable A
a::Int
end
julia function
Thank you Tim for your suggestion about creating functions returning
iterators. That sounds indeed like a very clean way to do it.
Mauro, thanks for the link. I read the paper by Logg and it seems
interesting. Do you have any references for how the mapping from the cells
to the actual finite
Mauro, thanks for the link. I read the paper by Logg and it seems
interesting. Do you have any references for how the mapping from the cells
to the actual finite elements is done?
No, I never got that far. But it doesn't contain any nodes, so
presumably those are all separate from the
Nat and I once started on a mesh library which implements some of that:
https://bitbucket.org/maurow/mesh.jl
but it has gone a bit stale.
In the spirit of Tim's response, it defines a big mesh datatype and then
helper dataytpes, for instance Vertices, which are just a thin wrapper
around the
Thank you Tim for explaining that more clearly. This morning's reply was
ENOCOFFEE :D
Please do file an issue, Nils, and thanks for investigating further.
On Wednesday, April 8, 2015 at 10:03:04 AM UTC-5, Tim Holy wrote:
Sounds like a bug, but I think what Patrick was trying to say is that it
Thank you.
On Wednesday, April 8, 2015 at 8:00:42 AM UTC-7, Tim Holy wrote:
It's a matter of taste, really, but in general I agree that the Julian way
is
to reduce the number of accesses to fields directly. That said, I do
sometimes
access the fields.
However, your iterator example is a good
Hi guys!
Here is [part of] some code I recently wrote for solving a physics problem:
https://gist.github.com/berceanu/010d331884848205acef
It's the first time I try to use Julia constructors properly (or
improperly?!) so I need your opinion on a couple of points.
1. On Julia's IRC channel I was
It already is Interval{Float64}. The issue is choosing defaults for a and b
which aren't inferrable from the type.
I think I'm convinced that just using NaN should work, with other domains
having a similar representation for parameters not set.
Sent from my iPhone
On 9 Apr 2015, at 6:41 am,
I have put in a pull request for a documentation change related to this
https://github.com/JuliaLang/julia/pull/10776
Please note it contains a few more edits that seemed appropriate.
Please approve or let me know what needs to change.
I would be happy to amend the documentation again if you
I can use sub to pretend a larger array is a smaller, or differently shaped
one. Is there functionality to allow me to treat several smaller arrays as
a larger one without copying them? In effect, mimicking hcat and friends,
but without copying data.
Proposal submission deadline extended by popular request to *Sunday, April
12 at 11:59pm EDT*.
AFAIK, there's nothing really like that right now, but what do you plan to
do with the data? Most linear algebra code, for example, calls out to
BLAS, which requires data to be contiguous (or at least strided) in
memory. Other code may or may not have this same restriction.
It should be
On Tuesday, April 7, 2015 at 5:53:09 PM UTC-4, Sheehan Olver wrote:
The current problem is
f=Fun(x-x^2,Chebyshev(Interval(a,b)))
represents a function on [a,b] as type Fun{Float64,Chebyshev}. But
sometimes one needs to convert numbers to functions a la
39 matches
Mail list logo
