Skip to main content

Bug Tracker

Side navigation

#11317 closed enhancement (plugin)

Opened February 10, 2012 10:10AM UTC

Closed February 10, 2012 03:42PM UTC

Last modified February 14, 2012 01:48AM UTC

Improvement suggestion for isNumeric() semantics

Reported by: sgbeal Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.1
Keywords: Cc:
Blocked by: Blocking:


isNumeric() currently (1.7.1) returns true/false, but that doesn't help the user all that much because it doesn't tell him what type of number, i.e. he doesn't necessarily know how to parse it into a number afterwards (as an integer or float, decimal vs hex vs exponential format).

A more useful semantic would be to return literal false for non-numbers and the parsed numeric value for numbers. The down-side is that this would introduce a slight backwards incompatibility for the value 0, since current code tests for truthy/falsy.

Attachments (0)
Change History (5)

Changed February 10, 2012 10:35AM UTC by sindresorhus comment:1

Don't see this as useful, as long as you don't need to know what the number was you can easily coerce any number into decimal by using a arithmetic operator.

+0xF -> 15
+020 -> 16
+15.0 ->15

Changed February 10, 2012 11:13AM UTC by sgbeal comment:2

Replying to [comment:1 sindresorhus]:

Don't see this as useful, as long as you don't need to know what the number was you can easily coerce any number into decimal by using a arithmetic operator.

Presumably (i haven't looked at the code) jQuery tries to convert the value to a number, so it would make sense to me to simply return it, rather than returning yes/no. That's simply mocking the user ("i know what the value is and now you may attempt to guess it yourself"). In many use cases that will lead to the double-decoding of numbers (once from jQuery and then again from the client code). Why make the client pay that conversion cost when jQuery has already paid it?

Changed February 10, 2012 01:45PM UTC by gibson042 comment:3

I've been thinking along these lines too, and could definitely go for something like the following:

ifNumeric: function( obj, fallback ) {
    obj = +obj;
    return isFinite( obj ) ? obj : fallback;

// deprecate?
isNumeric: function( obj ) {
    return jQuery.ifNumeric( obj ) != null;

Code like ret = parseFloat( orig ); return jQuery.isNumeric( ret ) ? ret : orig; (from jQuery.fn.width/height) would be reduced to return jQuery.ifNumeric( orig, orig );

Changed February 10, 2012 03:42PM UTC by dmethvin comment:4

resolution: → plugin
status: newclosed

I can see the utility of ifNumeric and if we used it in a dozen places like that it would make sense to define it just for the byte savings alone, even if we didn't expose it. But we only have two uses of it, and one doesn't fit that pattern, so I think we might as well stay with what we've already (just) documented and let this be a plugin or external code.

As for the original ticket suggestion, an isNumeric return value that broke 0 would be a big one in my book. This is a very simple one-line utility function so it's not hard to just ignore isNumeric and implement one line with whatever semantics you want in your own code. For example, perhaps you really want isInteger because real numbers and exponentials aren't valid in a particular case.

Changed February 14, 2012 01:48AM UTC by gibson042 comment:5

What if we can get it along with a 3-byte reduction?