alue", which implies that
> returning nothing is a good thing. I also don't feel it answers the
> "explicit is better than implicit" objection that started this thread,
> since the value being returned would not be evident in the code.
>
> On Wed, May 25, 2016 at
I like Stefans idea. Would be great to open an issue for that on github.
Tobi
Am Mittwoch, 25. Mai 2016 15:23:22 UTC+2 schrieb Michael Borregaard:
>
> To me, the suggested change seems to conflict intuitively with julia
> syntax. When using Julia at the REPL all expressions return a value,
> this problem resolvable soon.
>
> On Tue, May 31, 2016 at 1:11 AM, 'Tobias Knopp' via julia-users <
> julia...@googlegroups.com > wrote:
>
>> It would be great if this is resolvable. It took me quite some time to
>> determine that this is an issue in my own
statement within a function body evaluates to a return. A functional
language has no statements that are successively executed.
Am Donnerstag, 26. Mai 2016 08:08:00 UTC+2 schrieb Didier Verna:
>
> "'Tobias Knopp' via julia-users" <julia...@googlegroups.com >
> wrote:
It would be great if this is resolvable. It took me quite some time to
determine that this is an issue in my own code. My mental model was that
type stability is about the return type being statically dependent on the
input parameter types. That a local binding has changed is quite a
different
If you are prepared to make your code to not perform any heap allocations,
I don't see a reason why there should be any issue. When I once worked on a
very first multi-threading version of Julia I wrote exactly such functions
that won't trigger gc since the later was not thread safe. This can
Seems to be an issue specific for BigNum. I would expect in the line
s += i
new BigNum objects are created (and in turn allocated) and in turn the gc
will kick in from time to time and run the finalizers of the BigNum objects
that are not rooted anymore.
Am Dienstag, 15. März 2016 17:20:37
*shuffle!(vec(u))*
*will do what you want if **inlace shuffling is ok. Otherwise simply make a
copy before.*
Am Donnerstag, 24. März 2016 14:09:36 UTC+1 schrieb Arundhyoti Sarkar:
>
>
>
> Is there a way to shuffle matrix in julia like we do in matlab?
> I know shuffle(v) shuffles the vector
I also don't see the major issue with the inefficiency of meshgrid.
We do provide functions for evaluating
c = a * b
with a, b being vectors and we know that it is not efficient to do so (due
to the temporary vector introduced)
Tobi
Am Mittwoch, 9. März 2016 10:54:18 UTC+1 schrieb Christoph
tner fits in.
>
>
>
>
>
>
> On 22 Apr 2016, at 1:42 PM, 'Tobias Knopp' via julia-users <
> julia...@googlegroups.com > wrote:
>
> Well you mentioned "Thread support for Julia" and I could imagine that
> there are academic partners that could w
An alternative would be to instead make a collaboration with an academic
partner that is capable of working on this. There are various large open
source projects that use this model.
Cheers
Tobias
Am Donnerstag, 21. April 2016 16:56:57 UTC+2 schrieb Steven G. Johnson:
>
>
>
> On Wednesday,
ation of
> her/him carrying out basic software tasks: time spent on software
> development is not really a help getting an academic job.
>
> So the consulting model seems like a good alternative, I’ll look into it.
>
>
>
>
> On 22 Apr 2016, at 1:52 AM, 'To
As far as I understand it for now everything just works, because there is a
redirect.
Not sure if the new URL should be changed in METADATA.jl or if this will be
done automatically when the next release is tagged.
Tobias
Am Sonntag, 22. Mai 2016 19:14:21 UTC+2 schrieb Andreas Lobinger:
>
>
I think that Steven has a point here. Technically we have all in place and
Tims "Reexport" snipped is indeed the solution for creating Matlab like
toolboxes. Its quite interesting that nobody has yet done such a
metapackage. Maybe its because those users knowing the packages like the
While it certainly would be ideal to always get perfect feedback on issues,
it should be taken into account that Julia is a large piece of software and
that only finite resources are working on it.
Regarding when to release I think the core team just makes it right. During
0.3 we had
I also want to thank you Tony for the excellent release management! 0.5 is
an awesome release and in our research group the switch was absolutely
smoothly.
Thanks,
Tobi
Am Dienstag, 20. September 2016 21:28:04 UTC+2 schrieb Jeff Bezanson:
>
> Thanks Tony for your very hard work seeing this
But if it does not makes sense from your point to give a full matrix, why
does it make more sense to return a diagonal matrix? It is still lots of
heap allocated memory. So you replace a large performance trap with a
smaller one. What has been gained? We would still have to teach people the
https://github.com/JuliaIO/NRRD.jl
thats pure Julia
Am Samstag, 1. Oktober 2016 20:48:37 UTC+2 schrieb Steven G. Johnson:
>
>
>
> On Monday, September 26, 2016 at 9:59:15 AM UTC-4, David Smith wrote:
>>
>> I also don't need it to read image formats. Part of the reason behind
>> RawArray is to
Dear Michele,
yes the assumption is absolutely valid. Julia arrays are stored
column-major ordered in memory and this will not change. Since write does
only dump the memory on disk this is also not going to change.
Cheers,
Tobi
Am Mittwoch, 19. Oktober 2016 09:03:49 UTC+2 schrieb Michele
I want to second what Isaiah said. It can make sense to "bless" packages as
the default packages where people should look at.
But that people are doing independent approaches is the very nature of open
source which will (and should not) change. Often it even happens that
stating with a fresh
20 matches
Mail list logo
