[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extension to intmin/intmax to accept integer values?

From: Rik
Subject: Re: Extension to intmin/intmax to accept integer values?
Date: Sat, 10 Nov 2018 22:03:16 -0800

On 11/10/2018 11:28 AM, Carnë Draug wrote:
> On Sat, 10 Nov 2018 at 15:49, Rik <address@hidden> wrote:
>> The current intmin/intmax accept a string as an input.  For example,
>> intmax ("uint8")
>> => 255
>> How useful would it be to accept an actual integer class variable?  I could
>> see situations where one might have created an integer variable of some
>> sort, or maybe it was someone else's code so you have even less of an idea,
>> and you would like to know something about the limits.  Sample code
>> x = uint8 (3);
>> ... lots of intervening code ...
>> intmax (x)
>> => 255
>> Of course, one way to do this would simply be to get the class of the
>> variable and feed it to intmax.
>> class (x)
>> => uint8
>> intmax (class (x))
>> => 255
>> But, it still feels nicer to just query the variable directly.  If this is
>> of interest it isn't very hard to had to bitfcns.cc.  It would be an Octave
>> extension beyond Matlab's behavior.
> This seems like a very nice addition.  I don't think I ever just
> wanted to get intmax/intmin for a specific class, it's always the
> intmax/min of a passed argument.  Grepping for intmax on the image
> package and the core image functions, confirms the same.

I added support for this feature to intmin/intmax in this changeset
(https://hg.savannah.gnu.org/hgweb/octave/rev/df3f2e119944).  I also
simplified any instances of intmax (class (x)) in the scripts/ directory to
use the new calling form.

For good measure, I also added the ability to query a variable to flintmax
in this cset (https://hg.savannah.gnu.org/hgweb/octave/rev/afc3d1da58e5).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]