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
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
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
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
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
> 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
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
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:
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,
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:
>
>
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
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
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,
*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
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
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
This question is by no mean specific to Julia. You have to release the
software under GPL (v2/v3) and of course as a copyright holder you are
allowed to use it commercially. If you want others to contribute to your
package you need them to agree that the code will be used by you under a
On Julia 0.4 this is possible:
*julia> **Dates.unix2datetime(time())*
*2016-01-01T19:24:14.674*
*But its in UTC.*
*Cheers*
*Tobi*
Am Freitag, 1. Januar 2016 19:05:53 UTC+1 schrieb Andreas Lobinger:
>
> Hello colleagues,
>
> maybe i'm distracted, but how to get the current time
1 schrieb Tim Holy:
>
> On Monday, November 16, 2015 02:25:43 AM Tobias Knopp wrote:
> > After investigating this a little further I found that the key things I
> > am/was missing are:
> > - How to compose two RGBA values a and b. It turns out that this is the
> &
nterpolate into it (+ window
level, window brightness).
Cheers,
Tobias
Am Donnerstag, 12. November 2015 21:54:18 UTC+1 schrieb Tim Holy:
>
> On Thursday, November 12, 2015 12:15:46 PM Tobias Knopp wrote:
> > Thanks Tim, I tried to look into the code of Overlay but it wasn't to
> clear
>
])
> end
> dest
> end
>
> --Tim
>
> On Thursday, November 12, 2015 07:23:07 AM Tobias Knopp wrote:
> > Hi,
> >
> > I am using the OverlayImage type from the Images.jl package to overlay
> two
> > different grayscale images (tomographic
Hi,
I am using the OverlayImage type from the Images.jl package to overlay two
different grayscale images (tomographic data).
If I understand it correctly OverlayImage is restricted to colormaps that
go from black to a certain RGB value. Has anybody an idea how this could be
extended to
Julia is fully object oriented. The core of OO is not to write a dot
between an object and an associated function but that one has virtual
functions. Multiple dispatch provides just that.
Cheers
Tobi
Am Sonntag, 18. Oktober 2015 15:15:50 UTC+2 schrieb Simon Danisch:
>
> This design has at
Hi Tim,
this is great! I have used the Image type a lot in the past months as it
allows to carry image sizes with my 1D-5D arrays. Would be great if this
could be split into a single package. I am sometimes not entirely sure if
this type should be called Image because effectively it can also
What about the ZipFile package?
https://zipfilejl.readthedocs.org/en/latest/
Am Sonntag, 5. Juli 2015 04:26:46 UTC+2 schrieb Jeffrey Sarnoff:
After reviewing prior relevant topics, it is unclear that there is a
recommended way to work from within julia with multiple files compressed as
This is how most Julia code looks like. The methods are the interface and
thus which is exposed in public.
It is pretty natural to program this way when doing generic programming and
taking multiple dispatch into account.
I agree that this could be better documented somewhere but the solution
://en.wikipedia.org/wiki/Object_orgy although I don't think that
member functions are necessary at all to solve this (just a private
keyword, that keeps things visible only within the module (and submodules)
On Tuesday, July 7, 2015 at 7:15:23 AM UTC-4, Tobias Knopp wrote:
This is how most Julia code
Scott: Though it has never been verbalized in the documentation most people
follow the rule that fields are private. Discussions can be found in #1974.
Note that for immutable the fields are(!) the interface.
In practice this concept works very well and I have not seen people that
are used to
Hi Andreas,
the function cairo_copy_path does return a pointer to a cairo_path_t. So
the return value of your ccall is wrong.
Cheers
Tobi
Am Dienstag, 9. Juni 2015 20:00:39 UTC+2 schrieb Andreas Lobinger:
Hello colleagues,
i'm trying to get further interfacing to libcairo, but i somehow
https://github.com/JuliaLang/julia/issues/8066
Am Samstag, 6. Juni 2015 10:46:44 UTC+2 schrieb Scott Jones:
I have been trying to find out some way in Julia of getting information
about what the current file name line number is, and also the containing
module(s),
method or type, etc., in
Andreas,
unfortunately the Gtk/Winston/Cairo thing got a little unstable during the
last months. I tried two days a Winston/Gtk example and ran into the
Graphics issue. I think this shows that (unfortunately) the user base of
Gtk is still low. It would IMHO help to Winston rely on Gtk (i.e.
There is one exception though, which is keyword arguments
Am Samstag, 30. Mai 2015 03:49:45 UTC+2 schrieb Steven G. Johnson:
*No!* This is one of the most common misconceptions about Julia
programming.
The type declarations in function arguments have *no impact* on
performance. Zero.
/#nullable-types-representing-missing-values
Thanks,
Jiahao Chen
Research Scientist
MIT CSAIL
On Sat, May 30, 2015 at 2:08 PM, Tobias Knopp tobias...@googlemail.com
javascript: wrote:
There is one exception though, which is keyword arguments
Am Samstag, 30. Mai 2015 03:49:45 UTC+2
Furthermore using is not the only way to use a module. There is also the
import statement which has no issues with name clashes. I feel that the
primary issue seems to be documentation on good workflow. Plus we really
really need
import MySuperLogModule as m
Cheers,
Tobi
Am Dienstag, 26.
There might be differences as one can, in a source build, optimize the
system image to specific architectures. But I doubt that you will see
larger differences that are worth building julia from source. I think (but
am not 100% certain) that the code generation (LLVM) takes into account
the
Dear Scott,
I don't understand this GPL discussion. If you want to use Julia in a
commercial product you will have to think about deployment. I doubt that
you want to use the regular Julia installers for that. At this point its
about deleting two shared libraries (fftw and these sparse
Is the data in a file or already read into an array? If it is still in the
file you can simply read the data using the read function. If the data is
read as an Uint8 array you can use an immutable and reinterprete into it.
This does however not work if the C-struct would contain fixed-size
I have recently created functions for reading and writing a similar format
(Analyze/Nifti). Its not very complicated.
Something like the following to give you a start:
function load_edf(filename::String)
header = Dict{ASCIIString,Any}()
open(filename,r) do fd
version = bytestring(
Same thing for Gtk.jl
Its an absolute standard pattern to spawn a thread even for small workloads
in order to keep a GUI responsible.
Am Mittwoch, 18. März 2015 23:48:02 UTC+1 schrieb Jacob Quinn:
+1 to Mike's suggestion. I've looked into incorporating his auto-complete
functionality into
(x[:]', y[:]', z[:]'))) - ERROR: `bswap` has no
method matching bswap(::Array{Float64,2})
Any suggestions how to write big endian?
Am Samstag, 14. März 2015 20:05:50 UTC+1 schrieb Tobias Knopp:
not familiar with the vtk format but are you sure the the x,y,z
coordinates lay not directly
Hey Simon,
this sounds great. Will respond at the issue.
Cheers,
Tobi
Am Sonntag, 15. März 2015 18:48:51 UTC+1 schrieb Simon Danisch:
I actually just opened an issue
https://github.com/timholy/Images.jl/issues/267#issuecomment-81037699over
at Images.jl, to further modularize it, so that
not familiar with the vtk format but are you sure the the x,y,z coordinates
lay not directly after each other?
Could try:
write(fid, vcat(x[:]', y[:]', z[:]') )
Am Samstag, 14. März 2015 18:54:59 UTC+1 schrieb Christian Dengler:
Ty for your answers. I'm not familiar with vtk export on python,
The nrrd format seems to be similar (text header and binary data). You can
have a look at the implementation in Images.jl.
See https://github.com/timholy/Images.jl/blob/master/src/ioformats/nrrd.jl#L356
for the part where the data is written. Note that the data function is
only required here,
you can start with a simple matrix-vector or matrix-matrix product.
imfilter (Images.jl) is also a function that can benefit from
multithreading.
Am Freitag, 13. März 2015 04:52:37 UTC+1 schrieb Viral Shah:
I am looking to put together a set of use cases for our multi-threading
capabilities
.
On Monday, March 9, 2015 at 5:58:28 AM UTC-5, Tobias Knopp wrote:
Maybe it would be better to export the BLAS module instead of putting the
individual function into Base? Like we have Pkg.init() one would have
BLAS.axpy!
Am Montag, 9. März 2015 11:22:23 UTC+1 schrieb Mauro:
On my system I
Maybe it would be better to export the BLAS module instead of putting the
individual function into Base? Like we have Pkg.init() one would have
BLAS.axpy!
Am Montag, 9. März 2015 11:22:23 UTC+1 schrieb Mauro:
On my system I need to qualify it with Base, so Base.axpy! works.
On Mon,
unfortunately I have not found time to work on Juliette so this is only a
prototype and likely not working with newer Gtk.jl versions. But the aim
was indeed to make an IDE for Julia.
Cheers
Tobias
Am Donnerstag, 5. März 2015 09:36:03 UTC+1 schrieb Luke Stagner:
Robert,
Although it is
The error message is actually because the Gtk version was bumped to a new
version that comes with a nice default theme. Still not native but looking
better. The error is because there either the data for the icons is not
installed or some path is not properly said.
The issue is also discussed
Technologies like OpenGL have consumed masses of time and money as well :-)
Having worked on 3D visualization of large datasets (512^3) I am pretty
sure that one has to utilize the graphics hardware in order to obtain full
speed.
But it seems it all is about use cases. Exporting to html has
No I think its still only pointers to the type objects that are stored in
the array. But note that what Jameson wrote still holds. In ccall you can
assume that the type has C struct layout. No need to go for an immutable
there.
Tobi
Am Montag, 9. Februar 2015 19:00:15 UTC+1 schrieb Simon
import Base.show
function Base.show(io::IO, m::MyType)
print(io, This is MyType)
end
Am Montag, 9. Februar 2015 12:04:51 UTC+1 schrieb Evan Pu:
I have a type with a lot of fields, but when I want to print it I only
want to output the name field of that type.
So when I print an array of
:-) this is so funny! But still not a marketing slogan. Whats about:
The speed lays in the corner or
The truth lays in the corner...
Am Samstag, 7. Februar 2015 20:54:11 UTC+1 schrieb J Luis:
I'm going to refer to that plot from now on as nobody puts Julia in a
corner.
might be more
no
discussions in 0.4 dev cycle so IMHO we should be conservative about it (no
hastily actions in the end of a dev cycle)
Cheers
Tobi
Am Samstag, 24. Januar 2015 19:25:25 UTC+1 schrieb Stefan Karpinski:
Tobias, that is exactly the plan.
On Sat, Jan 24, 2015 at 9:29 AM, Tobias Knopp tobias
I think #8839 is a perfectly valid reason that some projects might have
not seen progress.
But there are others not on the list that have seen very much progress.
I would be a fan of making a feature freeze very soon. We have already very
important new features in 0.4 that justify a release:
-
of this new syntax for 0.4?
Thanks,
Petr
On Sunday, January 11, 2015 at 12:20:39 PM UTC-8, Tobias Knopp wrote:
The call syntax is part of 0.4
Cheers
Tobi
Am Sonntag, 11. Januar 2015 19:35:06 UTC+1 schrieb Petr Krysl:
On Sunday, January 11, 2015 at 10:22:05 AM UTC-8, Tim Holy wrote
The call syntax is part of 0.4
Cheers
Tobi
Am Sonntag, 11. Januar 2015 19:35:06 UTC+1 schrieb Petr Krysl:
On Sunday, January 11, 2015 at 10:22:05 AM UTC-8, Tim Holy wrote:
Already implement in julia 0.4.
Very cool! Just checking: are you saying that the solution I proposed
with
Am Sonntag, 11. Januar 2015 13:59:41 UTC+1 schrieb Chris Foster:
On Sat, Jan 10, 2015 at 11:46 PM, Tobias Knopp
tobias...@googlemail.com javascript: wrote:
That's interesting, I didn't know about the Kaczmarz method. Is it a
standard
method for your problem domain?
Standard is said
Hi,
I have learned from another mailing list thread that I con solve the normal
equation
X'X b = X'y
with the sparse matrix X by
Z = X'
b = cholfact(Z)\Zy
However, I need to solve
(X'X + lambda I) b = X'y
i.e. the regularized normal equation. Does someone know a direct method for
this?
:27 PM, Tobias Knopp
tobias...@googlemail.com javascript: wrote:
Hi,
I have learned from another mailing list thread that I con solve the
normal
equation
X'X b = X'y
with the sparse matrix X by
Z = X'
b = cholfact(Z)\Zy
However, I need to solve
(X'X
The recent commits in the threading branch look quite promising. I have not
tested it though.
One issue is that (if I understand it correctly) that some pthread stuff is
required while it would actually better to get this into libuv.
Am Dienstag, 6. Januar 2015 05:26:02 UTC+1 schrieb Viral
Is Gtk2 still working for you (with Gtk.jl)? I tried this last week and
faced several issues until I gave up.
Am Sonntag, 4. Januar 2015 10:43:29 UTC+1 schrieb Andreas Lobinger:
The code in Gtk/events.jl, signals.jl and cairo.jl is clearly gtk2 style
and working correctly. However in Gtk3
It is absolutely very much effort to specify the type when reading an hdf5
file. Simply because it may not be known at compile time.
By the way, the array dimension is in various applications also a dynamic
parameter not known at compile time. I once had to dispatch these
uncertainties to a
I cannot judge on your proposal as I have not much experience with macros
(nor with staged functions). Jameson surely can because he has a clear
opinion when to use macros and when not.
I just wanted to make clear that defining the type can be a serious issue.
Further I don't really see whats
Or reading an array from an hdf file. In that case the array type is not
known until runtime. Or it would be tedious if the type would have to be
explicitly provided
Am Freitag, 2. Januar 2015 21:35:46 UTC+1 schrieb Jiahao Chen:
the most important use case for type instability seems to be
Hi Ismael,
why do you think that master is more frequently broken in Julia than in
other projects?
This really does not happen often. People develop in branches and after
serious review they are merged to master.
This discussion further is to isolated and does not take into account that
Julia
not).
Cheers,
Tobi
Am Donnerstag, 1. Januar 2015 10:04:11 UTC+1 schrieb Tobias Knopp:
Eric (and Keno),
My statement that Julia is from and for researchers has been made in a
certain context where I wanted to explain why Julia has a different
development model than a programming language
Eric (and Keno),
My statement that Julia is from and for researchers has been made in a
certain context where I wanted to explain why Julia has a different
development model than a programming language that is development within
Google.
My personal opinion is that Julia is a great general
I have to say that Jeff and Stefan (and of course all the other from the
core team) do an awesome job. I have been waiting myself for responses of
Jeff but with a software project that big it is absolutely normal that one
will not always get an immediate response to every bug report.
If
Hi Andreas,
In https://github.com/tknopp/Julietta.jl/ you will find various uses of
signal_connect. Unfortunately I don't think that Julietta is currently
working due to some changes in the listview interface.
Other than that I usually look at the test file.
Cheers,
Tobi
Am Dienstag, 30.
@Isaiah :-)
Am Dienstag, 30. Dezember 2014 14:54:47 UTC+1 schrieb Tobias Knopp:
Hi Andreas,
In https://github.com/tknopp/Julietta.jl/ you will find various uses of
signal_connect. Unfortunately I don't think that Julietta is currently
working due to some changes in the listview interface
This looks pretty cool!!!
Would be awesome to integrate it into the Gtk.jl documentation!
Am Dienstag, 30. Dezember 2014 15:59:15 UTC+1 schrieb j verzani:
As well, there are some examples in some unfinished notes here:
https://gist.github.com/jverzani/836e4c065862cab4ee50
On Tuesday,
:-) Well what is called julia runtime does exactly that: generate code on
the fly (just in time)
Julia currently has no interpreter but Jameson has some experimental code
to use an LLVM interpreter
Tobi
Am Dienstag, 30. Dezember 2014 18:22:54 UTC+1 schrieb Spencer Russell:
Bummer. Some
The post reads like a rant. As every software project out there Julia has
bugs. So is it really necessary to complain about bugs of an open source
project in a blog post?
Am Montag, 29. Dezember 2014 18:30:26 UTC+1 schrieb Tim Holy:
In my personal opinion, his post is a mix of on-target and
I think Jason has a point here. The lack of module merging (see exportall,
reexport,...) makes include more necessary than it might be. Further we
really need #4600.
To be honest: When going through packages I have found myself using the
includes to understand the package structure.
Cheers
know Dan personally and happen to know that this
is where he's coming from.
On Mon, Dec 29, 2014 at 3:58 PM, Tobias Knopp tobias...@googlemail.com
javascript: wrote:
So you dislike Julia and encountered several bugs. Reading your posts is
like you want to blame someone for that. If you
.
On Mon, Dec 29, 2014 at 4:27 PM, Tobias Knopp tobias...@googlemail.com
javascript: wrote:
Stefan, ok. My advice was actually also constructive. I have tried
various open source software in my life and there were several that were
broken. But then I have simple not used it if I am not satisfied
Hans,
yes this can be frustrating. But Julia is in flux and I have to say that I
am very happy that changes are reverted if they turn out to be not
practically (e.g. .+ which I also was not happy with).
One important thing to note: If you don't like this back and forth it
should be better to
I suppose that the fft limitation is due fftw supporting only float32 and
float64.
I am not sure if simd supports float16. If not you should not expect any
speed gains.
Cheers
Tobi
Am Dienstag, 23. Dezember 2014 11:56:46 UTC+1 schrieb Mark B:
I was wondering how Julia supports half
Sorry if this has already been answered. Its about optional plotting
functionality in a package. More precisely I want to have some Winston /
Gtk based plotting things and some PyPlot plotting routines.
Is there a possibility to have submodules in a package so that the main
module can be used
on Mike Innes's require macro. Here is an
example in action for supporting multiple plotting mechanisms:
https://github.com/one-more-minute/Jewel.jl/blob/b0e8c184f57e8e60c83e1b9ef49511b08c88f16f/src/LightTable/display/objects.jl#L168-L170
On Tue, Dec 23, 2014 at 9:42 AM, Tobias Knopp tobias
, Dec 23, 2014 at 9:56 AM, Stefan Karpinski
stefan.k...@gmail.com javascript: wrote:
Doing computation with Float16s is not really reasonable - the IEEE
standard
describes this as a format that is only for storage.
On Dec 23, 2014, at 9:23 AM, Tobias Knopp tobias...@googlemail.com
Julia 0.4dev is also not recommended to be used...
Am Samstag, 20. Dezember 2014 19:18:11 UTC+1 schrieb Milan Bouchet-Valat:
Le vendredi 19 décembre 2014 à 16:27 -0800, Dahua Lin a écrit :
NumericExtensions.jl was a stopgap.
Now that we have callable syntax and much more optimized
please have a look at https://github.com/JuliaLang/julia/pull/6122 which
looks like the way to go (once merged)
Cheers
Tobi
Am Montag, 8. Dezember 2014 20:18:18 UTC+1 schrieb Josh Langsfeld:
On Monday, December 8, 2014 12:15:23 PM UTC-5, Utkarsh Upadhyay wrote:
I have just tried playing
Maybe use the Julia wrapper for cairo_surface_flush?
Am Montag, 3. November 2014 17:27:23 UTC+1 schrieb cormu...@mac.com:
This is my Hello world for Cairo in Julia outputting to PNG:
using Cairo
imwidth = 200
imheight = 200
c = CairoRGBSurface(imwidth,imheight)
cr = CairoContext(c)
Yes, Jakes suggestion looks good. When I wrote the embedding doku I also
played around with several internal functions and it turned out that
jl_eval_string is very versatile and can be used in various circumstances.
Einar: Would be great if you could test it and improve the embedding
I don't really know if this is a bug or if there is some good technical
reason for this.
What seems to happen is that the definition
A(x, y) = new(x, y + 1)
removes the default constructor. You can see this by typing A on the REPL
(or methods(A))
Am Dienstag, 26. August 2014 09:14:10 UTC+2
Magnus,
Please feel free to file a new issue. Even if it is intentional it might
have to be better documented.
Cheers,
Tobi
Am Dienstag, 26. August 2014 10:41:30 UTC+2 schrieb Magnus Lie Hetland:
Hm, yes. Is this somehow related to the default constructor stuff added in
0.3 (linked to
The ArrayView package will give similar though not equivalent possibilities.
See also https://github.com/JuliaLang/julia/pull/5556
and https://github.com/JuliaLang/julia/issues/5932
I think there is also a transpose type that would allow to reverse strides.
Cheers,
Tobi
Am Dienstag, 26. August
The multiline comments #= ... =# were introduced in version 0.3.
If your VMRecommender.jl code has a comment that starts with #= this will
not be parsable anymore with Julia 0.3.
Cheers,
Tobi
Am Montag, 25. August 2014 16:21:43 UTC+2 schrieb Steven Sagaert:
when running a file
There is https://github.com/JuliaLang/julia/issues/4600 but there was
recently quite some dicussion on the julia-dev mailing list as well as
https://github.com/JuliaLang/julia/issues/8014
Cheers,
Tobi
Am Montag, 25. August 2014 16:29:03 UTC+2 schrieb Andrei Zh:
Valentin, thanks for your
:-)
If you are interested in the history of multiline comments:
https://github.com/JuliaLang/julia/issues/69
Am Montag, 25. August 2014 16:41:13 UTC+2 schrieb Steven Sagaert:
Hi Tobias,
Thanks. I had lines like #= blabla and those were the
problem.
On Monday, August 25,
Thats for a reason. Float64 and Float32 are the same on 64 and 32 bit
computers. Its only the integer types where this matters.
Am Montag, 25. August 2014 21:38:44 UTC+2 schrieb Roy Wang:
Thanks Tom. Pweh, that's what I suspected.
I glanced at boot.jl, and it doesn't seem Julia has a
systems. Thanks.
On Monday, 25 August 2014 15:48:30 UTC-4, Tobias Knopp wrote:
Thats for a reason. Float64 and Float32 are the same on 64 and 32 bit
computers. Its only the integer types where this matters.
Am Montag, 25. August 2014 21:38:44 UTC+2 schrieb Roy Wang:
Thanks Tom. Pweh, that's
I tagged a new release 0.2.3. Because I am not a regexp guy I am not 100%
sure if the open PR is ok. So for now I just solved part 1 of the problem.
Cheers,
Tobi
Am Donnerstag, 21. August 2014 20:30:55 UTC+2 schrieb Xiao FENG:
Hi there.
There are two issues with this package
1. The
function foo4(x,y)
is also a valid way that allows most flexibility. From a performance point
of view all functions are equally fast.
Specifying types is not done for performance reasons but to allow for
dispatching on the type. foo2 and foo3 are of course semantically different
because foo2
Hi Spencer,
yes the ScalarOrArray type will work and be fast. In that case you could
have also not specified the types at all.
We call this duck typing which is a term that comes from the python world.
I think there is no preferred way to do this in Julia and there are
people that favor the
1 - 100 of 225 matches
Mail list logo
