3 ms·
The problem is that here the "generic" tools like "apply" are not really generic. Hence you can not use your intelligence and creativity to deduce a working pro
by Gravityloss 14y ago
The problem is that here the "generic" tools like "apply" are not really generic. Hence you can not use your intelligence and creativity to deduce a working program using a small toolset that you know fully.
Instead you must use a huge number of special tools that do only a few things. The code is hard to read, hard to write, slow, the compiled version is big. It is also error prone since you must use a large number of different paradigms. Some might have their arguments slightly differently. It's produced by googling for everything (or if there's a decent builtin help system, using that).
It seems strange that such concepts, like generic data types, operators and functions are not more widely spread. For example if you can calculate "max(a-b)" even if "a" is a matrix and "b" is a scalar, that's already quite nice. This can increase productivity a lot.
Since such design models are so fundamental, they are rarely found in "matlab-like" extensions for other programming languages: instead you must constantly do type conversions and transformations by hand and use awkward middle man functions to access data types. Most of your code is housekeeping and little actual progress.
See for example the problems with Julia where column and row vectors are totally different types: http://2pif.info/op/julia.html http://2pif.info/op/julia.html
- pygy_ 14y ago> See for example the problems with Julia where column and row vectors are totally different types: http://2pif.info/op/julia.html http://2pif.info/op/julia.html That was one year ago. They are still different types, but they behave as you would expect wrt arithmetics. julia> x = [1,2,3] 3-element Int64 Array: 1 2 3 julia> y = [1 2 3] 1x3 Int64 Array: 1 2 3 julia> y' 3x1 Int64 Array: 1 2 3 julia> x + y' 3x1 Int64 Array: 2 4 6 Their size and dimensions are still different, though, but it is mostly a concern for library writers. julia> ndims(x) 1 julia> ndims(y) 2 julia> ndims(y') 2 julia> size(x) (3,) julia> size(y) (1,3) See https://groups.google.com/forum/?fromgroups=#!msg/julia-dev/W2C9-HbXH3o/P8A8jo7FHSoJ https://groups.google.com/forum/?fromgroups=#!msg/julia-dev/... for the discussion that resulted from that post. Edit: I should add that there's now a mailing list dedicated to statistics with Julia: https://groups.google.com/forum/#!forum/julia-stats https://groups.google.com/forum/#!forum/julia-stats
- Gravityloss 14y agoThanks, I actually went and tried myself as well and saw the same. So quite good though not yet fully "symmetric". >> z=size(a) (3,) >> z[2] BoundsError()
- alok-g 14y agoThis is pretty much the only thing that I do not like about Julia. Matlab also uses this concept, and I have had my Matlab code broken several times because of this issue.
- foobarqux 14y agoTrailing singleton dimensions in N-D arrays was a far worse problem that I believe Julia fixed.
- tel 14y agoI was totally unable to learn R until I discovered plyr, which, goes a long way to making those operations more generic.
- disgruntledphd2 14y agoPlyr is wonderfully expressive, but it breaks down when you have hundreds of levels of a factor. tapply, on the other hand keeps trucking on up to a couple of thousand with very few problems. Hadley says that he may use data.table for plyr2 though, which would make my life a lot better.