What if the file name is only known at run time?
I'm all for better lint and warning tools to help those who want to remove
type stability, but bear in mind that not everyone does. I for one really
like the convenience of dynamic typing for non-performance-sensitive code.
On 3 January 2015 at
There is type instability here, actually – the macro doesn't change
anything with regard to types.
coltype = get_vector_coltype_from_file(filename)::?
load_vector_from_hdf5_file(filename, vecname, coltype)::?
get_vector... is not type stable, which means that the entire block isn't –
there's no
well, I've just opened a pull request where qrfact is type-stable (using
staged functions of course) see here:
https://github.com/JuliaLang/julia/pull/9575
The same could be done for the other functions you mentioned (e.g.
factorize, sqrtm, etc.) and I'll do if the current one is positively
it should still work if the file name is known only at runtime, consider
the following script:
filename = myrandomfile*string(rand(1:5))*.hdf
vecname = myvec
@load_vector_from_hdf5_file(filename, vecname)
w/o specifying types, w/o type instability, and file name decided at
runtime.
I have
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
There is type-instability only at global scope, that's the point. So when
you are using the repl (or just using the global scope) you won't have to
write types. My suggestion is only to disallow type-instability at inner
scopes so they become fully statically typed; the next step would be to
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
But using a function for this is wrong because macros allow you to load the
vector at runtime w/o specifying types and without inner scope
type-instability. So why insisting using a function instead of a macro? The
only scenario I can think of is if the name of the file is only known at
Not saying it's impossible, but these might make interesting reading:
https://github.com/timholy/HDF5.jl/issues/88
https://github.com/timholy/HDF5.jl/issues/83
https://github.com/timholy/HDF5.jl/issues/37
If I have file1.jld and file2.jld, both containing the variable x but the
types are
Right, so you have the high-level, dynamic part of the language for basic
interactive use and the harder to use, fully typed part for the real
coding.
Except that already exists – you can just use Python and C. The split
between high and low-level is exactly the problem that Julia was designed
to
Hi, I Just want to discuss this idea: type instability in functions is a source
of slowness, and in fact there are several tools to catch instances of it. I
would even say that ising type instability in functions is considered bad style.
the most important use case for type instability seems
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
the most important use case for type instability seems to be allowing a
good interactive experience in the Repl.
In many cases, type instability is indeed a performance penalty and
indicative that better code can be written. However, I would argue that the
most important use case for type
13 matches
Mail list logo
