# Difference between revisions of "User talk:Kri"

Jump to navigation
Jump to search

Carandraug (talk | contribs) (→repmat different syntax: reply) |
|||

Line 20: | Line 20: | ||

:::: --[[User:Carandraug|carandraug]] ([[User talk:Carandraug|talk]]) 02:41, 22 September 2014 (PDT) | :::: --[[User:Carandraug|carandraug]] ([[User talk: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. —[[User:Kri|Kri]] ([[User talk:Kri|talk]]) 03:13, 22 September 2014 (PDT) |

## Revision as of 03:13, 22 September 2014

## 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?

- 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.

- I don't understand the issue. There was missing functionality in

- 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.

- But there are plenty of cases where Octave implements something before Matlab. A perfect example is bug #42487 about Matlab having finally implemented

- 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)