MatlabCompat.jl already
exists: https://github.com/MatlabCompat/MatlabCompat.jl
On Tuesday, November 17, 2015 at 2:52:30 PM UTC-8, Sheehan Olver wrote:
>
>
> For both non-integer indexing and linrange, it seems that complaints about
> "hard for newcomers" really mean "hard for newcomers from Matlab". Maybe
> there should be a MatlabCompat.jl package that restores Matlab behaviour.
> For some things, this can be done without overloading base:
>
> *julia> **module MatlabCompat*
>
> *linspace(a,b,c)=collect(Base.linspace(a,b,c))*
>
> *end*
>
> *julia> **using MatlabCompat*
>
> *julia> **linspace=MatlabCompat.linspace*
>
> *julia> **linspace(1,2,3)*
>
> *3-element Array{Float64,1}:*
>
> * 1.0*
>
> * 1.5*
>
> * 2.0*
>
> *julia> **Base.linspace(1,2,3)*
>
> *linspace(1.0,2.0,3)*
>
>
>
> As long as no package depends on MatlabCompat, then the issue of
> non-standard code will be localized.
>
>
>
>
> On Wednesday, November 18, 2015 at 7:32:17 AM UTC+11, Milan Bouchet-Valat
> wrote:
>>
>> Le mardi 17 novembre 2015 à 02:46 -0800, Peter Kovesi a écrit :
>> > Thanks Eric. Yes I appreciate that the language is highly flexible
>> > and one can do lots of things. I don't want to get hung up on using
>> > indexing with integer valued floats in particular, my concern is more
>> > philosophical
>> I'm sympathetic to the idea of allowing indexing with reals, but so far
>> I haven't found very compelling examples to support my position. Could
>> you provide concrete use cases where this makes life easier, at least
>> for newcomers? Julia's development is often driven by actual
>> experiences of what is really useful and what isn't.
>>
>>
>> Regards
>>
>> > For much of what I do I am wanting to solve some technical problem
>> > within an environment that involves a minimal overhead in solving the
>> > coding problem. If, as I am developing my solution, I end up writing
>> > some code that happens to use indexing with integer valued floats, or
>> > would find a meshgid() function handy, then I do not want the
>> > language to 'get in my way'. (Hands up everyone who has their own
>> > implementation of meshgrid() !) Yes I know these things are not
>> > required and are not efficient but I may find them handy and I don't
>> > want to be distracted from solving my technical problem while I
>> > attend to any finicky language issues. I want to develop my
>> > initial solution with the minimal amount of code and the minimal
>> > number of special data types. Later, when I have things solved, I
>> > can return to the code and re-engineer it for efficiency
>> >
>> > It is extremely attractive that you can engineer your Julia code to
>> > be highly efficient but I am hoping the language can develop in a
>> > way that does not compromise simplicity and convenience.
>> >
>> > Cheers
>> > Peter
>>
>
