linspace

[asilvas]

There seems to be nothing that truly emulates this behavior. Similar topic #61

I can kinda hack it with math.range but it's pretty hacky to get the exact matrix size you desire.

[josdejong]

Thanks for the suggestion.

Anyone interested in implemented linspace?

[jwilber]

@josdejong I'll happily give it a go if it's still open?

[josdejong]

Thanks for your offer Jared, that would be great.

[josdejong]

@jwilber are you still interested in implementing linspace?

[matthras]

I'm happy to give it a crack if there's still no activity from @jwilber

May I verify that this is the specification intended for linspace ?

http://au.mathworks.com/help/matlab/ref/linspace.html

[harrysarson]

That looks good to me 👍

Also worth taking a look at the scipy docs: https://docs.scipy.org/doc/numpy/reference/generated/numpy.linspace.html

The two look fairly similar but it would be worth seeing if they differ at all.

[josdejong]

Thanks @matthras that would be great!

As far as I know the API is quite straightforward and works the same in all major math applications:

linspace(start, end [, num])  // end included

Correct?

We could discuss about the best default value for num, like 100 (matlab) or 50 (python)?

[matthras]

There's two additional optional arguments in the Numpy implementation which look just as easy to implement (thanks for the link, @harrysarson!):

• endpoint : bool, optional - If True, stop is the last sample. Otherwise, it is not included. Default is True.
• retstep : bool, optional - If True, return (samples, step), where step is the spacing between samples.

I'm not sure about dtype, but I'm not experienced enough with OOP/typed languages to know/be aware of necessary use cases.

Re: Default value for num: 100 makes more sense to me, but I'm happy to listen to any reasons as to why it should be 50.

Let me know if it's preferred I ask questions at some Slack/Discord/Gitter/IRC/group chat, otherwise I'll keep commenting here with questions/updates.

[harrysarson]

I would argue that we should implement lispace without these optional arguments and then if anyone comes back with a use case and complaining about the lack of these arguments then we can add them. Otherwise, we might aswell keep the initial implementation as simple as possible.

Let me know if it's preferred I ask questions at some Slack/Discord/Gitter/IRC/group chat, otherwise I'll keep commenting here with questions/updates.

As far as I know, this is the best place 😄

[matthras]

Function skeleton has been written, I've got a solid idea of how the internals should look, then I'll figure out what tests should be written.

Questions that I currently have:

• It looks like using typed() means that tests don't need to be written for type-checking, am I correct on that one?
• What's the philosophy/ideas regarding on dealing with number/BigNumber interactions?

I've noticed in addScalar.js and multiplyScalar.js that separate cases are written for number/number and BigNumber/BigNumber interactions, but not for number/BigNumber interactions and vice versa - am I missing something in the code or is that a disallowed combination (i.e. the user will have to coerce the number value into a BigNumber type if such a scenario happens)? In other words, should a user be able to do something like add(BigNumber, number)?

I'm planning to test these over the weekend just to verify my thoughts/inferences, but figured I should leave my questions there in case I forget!

(You can assume that I have an understanding of why BigNumber exists and the different arithmetic functions used for handling BigNumbers!)

[josdejong]

Good questions @matthras .

1. An option like dtype is in mathjs typically handled in two ways:

   • The type of numeric output is normally determined from the input arguments. I.e. if linspace is called with numbers in the input, the output will be numbers too. When the input is called with one or multiple BigNumbers, output will be BigNumbers.
   • Matrix type can sometimes determined from the input and sometimes not. In that case you can often pass the type as a parameter and if not provided, the function falls back to the config option math.config().matrix to determine the type of output matrix. For example, math.ones cannot determine whether to output a DenseMatrix or SparseMatrix or Array, therefore it first looks to its optional third argument format and if not provided uses the config setting.

2. When using typed you indeed don't have to worry about checking the types of input arguments, that's what typed-functions do for you.

3. Regaring "number/BigNumber interactions": most functions have implementations for example for add(number,number) and add(BigNumber,BigNumber) and not for mixed calls like add(number,BigNumber. These mixed cases are handled by typed-function which in such a case will convert the number argument into a BigNumber and then call add(BigNumber,BigNumber.

4. For the linspace implementation, you can probably create one generic implementation handling any numeric type (instead of specific implementations for number, BigNumber, etc. Something along these lines:

   const linspace = typed({
     'number | BigNumber | Fraction, number | BigNumber | Fraction, number | BigNumber | Fraction': function (start, end, step) {
       // now, start, end, step can be different numeric types
       // this works fine here as long as we use functions like addScalar and multiplyScalar 
       // to operate on them, instead of + and * which only work on numbers
     }
   })