User talk:Kri

repmat different syntax

Regarding your recent changes, the best place to make note of that is on the Octave bug tracker. Also, you did not specify in what case the syntax is different, so I guess, maybe you're referring to this?

Yes, that seems to be what I meant, thank you for linking to the bug report. When I wrote that the syntax is different, I meant that the syntax differed for some case. I don't think the syntax should differ from that in Matlab in any case. But why did you remove the note about making sure Octave is compatible with Matlab and vice versa, don't you think that is worth mentioning? —Kri (talk) 05:04, 21 September 2014 (PDT)

I don't think it's worth mentioning on the list of project as it is not a project, just like we do not make reference of the Octave coding standards there. It wouldn't be the right place for it. And even if it was, I disagree with that opinion and considering the amount of Octave features missing from Matlab, I would say that so do most of Octave developers. One should be careful to not implement something that could clash with exiting Matlab functionality but its' perfectly fine to implement things that are missing in Matlab. --carandraug (talk) 07:51, 21 September 2014 (PDT)

Okay, that makes sense. In this case however, Octave and Matlab can both repeat arrays in more than two dimensions, but require different syntaxes for doing so. So when Octave eventually will support the syntax used in Matlab, it will support two different syntaxes for doing the same thing, which is not necessarily a good thing. It would probably have been better if the syntax used in Matlab had been implemented from the beginning. Do you agree with me?

In that case maybe we should say something about that to the Octave developers. Where do you think it could be mentioned in that case?

Or did Octave implement that function before it was implemented in Matlab? I haven't checked that. Because in that case it makes more sense that it is implemented the way it is. —Kri (talk) 09:05, 21 September 2014 (PDT)

I don't understand the issue. There was missing functionality in repmat but that was not caused because there was something else preventing it being fixed. It's just that no one had noticed until now. You will notice that the alternative syntax, [sz1, sz2, ... szn], also exists in Matlab.

But there are plenty of cases where Octave implements something before Matlab. A perfect example is bug #42487 about Matlab having finally implemented issymetric. Octave implemented it in 2002, while Matlab only implemented it in 2014. Matlab version was not compatible with Octave despite the fact that Octave kept it interface stable for 12 years . Fortunately, it does not always causes such problems. Another example is the function flip. Octave implemented flipdim in 2004. Matlab implemented flip in 2014. This function does exactly the same thing, it only has a different name.

Octave has plenty of extra syntax, functions, and function options that are still missing in Matlab. I don't see why Octave developers should be forced to stay behind and simply imitate Matlab design. There is already a lot of care taken by Octave developers so that Matlab code can continue to run on Octave, but that doesn't mean it should not implement new things which are useful additions to the language, just because Mathworks hasn't done so yet.

--carandraug (talk) 02:41, 22 September 2014 (PDT)

If the function is implemented later in Matlab than it is in Octave, then I guess it is not much to do about it. And in this case, if the alternative syntax also exists in Matlab, then I guess it is not a problem either.

What I mean is that if we support alternative syntaxes that don't exist in Matlab, Octave scripts that use those syntaxes will not be portable to Matlab unless they are rewritten. And people will continue to use the alternative syntaxes unless they are completely removed from Octave, so people will (accidentally) continue to write scripts that are not portable to Matlab. That I see as a problem. This is of course not possible to avoid if we develop a functionality before Matlab, as in the examples you mentioned. —Kri (talk) 03:13, 22 September 2014 (PDT)

That is up to the authors of said code. If they want to write code that works in both Matlab in Octave, they must take care to avoid features missing in Matlab. This is in no way different from Matlab users who should take care to avoid using features that are still missing in Octave if they care about their code being used in Octave. It is not the Octave developers responsibility to prevent this. Unfortunately, the following will sound like a joke for many. If Matlab code is using some new Matlab code, it is perfectly acceptable to blame Octave developers and ask them to implement that missing function. But if Octave code is not working in Matlab because it uses a feature Mathworks has not implemented, no one asks Mathworks to implement it. The blame seems to fall on Octave developers for implementing things before Mathworks. Next time you face such a problem, I'll suggest you fill a bug report with Mathworks about missing feature and Octave compatibility.

--carandraug (talk) 03:42, 22 September 2014 (PDT)

Okay, creating a bug report seems reasonable. Still, don't you think it's a good idea to add such a note to Octave developers? Where should we put it in that case? —Kri (talk) 07:27, 22 September 2014 (PDT)

To clarify things, I never intended to put any blame on anyone; If it seemed like that I'm sorry. I think Octave is a great product and I am not at all upset at anyone or at the way it is implemented, even though I might have sounded a bit harsh when I wrote the note. I just want to help improve Octave and see a potential in doing so here. —Kri (talk) 13:24, 22 September 2014 (PDT)