| Re: [eigen] LinSpaced() API |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] LinSpaced() API
- From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Thu, 22 Jul 2010 14:06:24 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=KPdZDxjMjRXpPInYuyTUZ9nD9eOE2e8HkyrT25vIrAE=; b=UCTtelmpfK7ZEhsudE4bIOYPjnlmfCiP6tRzp3k7iDGP4cu6NF/43x84kBYwzw4D0c 5fRPoWKQ9cgdk8PHR0z3QXcM3TZN9kCBUiykamL7ogC30fhXie/X6kjdjdSmXY5W21tD ELkuRux5c52KYSwgH6jA8hr/uTNK6edxEEH98=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=BRW32DLgYunOdeNVtOPPsAzypx5F8y1ZGKk+OicGqDZaBi+ZD4TA0hOkvwWfmCLRJC i2OSp19wJswwOG1wRYOp5R1zpxiD8MaU52o1u+jobUrZml8UmR6o9cpFuosLINFzxDKR w+DjVj4QSazJEDbLnlpK4Sc6BUANs4W1uG4aE=
Done.
On Thu, Jul 22, 2010 at 1:41 PM, Hauke Heibel
<hauke.heibel@xxxxxxxxxxxxxx> wrote:
> Hi Jitse,
>
> I wrote those functions....
>
> On Thu, Jul 22, 2010 at 1:13 PM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx> wrote:
>> I'm adding some bits to Tutorial page 5 (advanced initialization).
>
> Thank you for doing this since I am hardly finding any time at the moment..
>
>> While
>> doing this, I noticed the order of the arguments for the static methods
>> Constant() and LinSpaced() for vectors:
>>
>> Constant(size, value) versus LinSpaced(low, high, size)
>>
>> I guess that the order of arguments for LinSpaced() mirrors the order for
>> the Matlab function linspace. However, it does seem inconsistent when
>> compared to the order of arguments for Constant(). I think that consistency
>> within Eigen is more important than consistency with Matlab, so what about
>> changing the order to LinSpaced(size, low, high)?
>
> That's true and I am fine with switching. Last chance for breaking the
> API, right?
>
>> Additionally, I note that there is no fixed-size variant without the size
>> argument. Is there any reason for that?
>
> I cannot recall why I did not implement this. It should be simply to
> add an overload. I can do both changes right now.
>
> - Hauke
>