>
> Inasmuch as we don't understand the reasoning behind how your proposal
> partitions the input value, providing a coherent name for those parts is a
> non-starter. Again, why does your proposal treat *some* zeros different
> from non-zero digits in the same position, or different from previous or
> subsequent zeros encountered within the number?
Who is "we"? Are you speaking for viewers of this proposal other than
yourself?
The proposal is just that, a proposal. The concept is the _spread_ input
integer or decimal to an array. In the original proof of concept, _if_ the
decimal portion contains zeros followed by a digit that is not a zero, that
portion of the decimal up to and including the first non-zero digit is
included in the decimal portion of the array. _If_ there are digits
following the first number that is not a zero in the decimal portion of the
array, those digits are spread to the adjacent elements of the array. Why:
That is the approach used to spread the number to an array, and to handle
those leading zeros following decimal point.
Use cases:
- Get any portion of a number or decimal as a discrete portion of the number
- Manipulate discrete portion of a number using array data structure, then
covert back to number
- Ability to avoid using multiple Number, Math or remainder operator
procedures to get discrete portions of a number
- Graphing, statistics, fuzzy logic operations using number representation
as an array
On Tue, Mar 12, 2019 at 6:07 PM Jeremy Martin <jmar...@gmail.com> wrote:
> The same way that Intl.NumberFormat.prototype.formatToParts does.
>>
>
> Intl.NumberFormat is used for localized string formatting. Even the
> numeric parts that `formatToParts()` returns are still represented as
> strings, and are not expressly intended as inputs for downstream
> mathematical operations. Inasmuch as it does not fix, improve upon, or
> otherwise specifically relate to mathematical operations (*especially*
> with respect to floating point considerations), I cannot see how this
> proposal does, either.
>
> Though takes the concept one step further by *spreading* each digit to an
>> array. If the number has a decimal, the decimal portion is set at a single
>> element of an array. If the decimal begins with a 0, continue until the
>> first non-zero number is reached, include that number in the decimal
>> portion within the array, and the remainder of the decimal portion is
>> spread to remainder of array elements
>>
>
> That is *very* specific behavior that, as we still don't understand your
> motivation, we cannot even begin to appreciate. *Why* is that
> functionality something that you or developers in general might want? Why,
> for example, would we only care about direct access to the digit in the
> hundredths place when it's *not* a part of this very specific sequence?
>
> The proposal improves what is broken by not returning broken results
>> relevant to decimal numbers.
>
>
> It does not. This is exactly why I attempted to address some potential
> confusion around Floats before.
>
> var n = numberToArray(0.3) // [0, 0.3]
> arrayToNumber(n); // 0.3
>
> That resulting 0.3 is "broken" in the exact same sense as it was when it
> was fed into the transformation.
>
> The proposal allows users to get and set any portion of a number using
>> indexes of an array, which can then be converted back to a number.
>
>
> It does not. It allows getting and setting portions of numbers at an index
> in an array so long as that position doesn't belong to an (arbitrarily?)
> specified sequence of one or more zeros and a trailing non-zero digit.
>
> You might as well state that Intl.NumberFormat.prototype.formatToParts
>> does not have any use.
>>
>
> Of course it has use. Just not as framed or cited within the context of
> this proposal.
>
> The proposal is asking you people who claim to be specification authors to
>> _name_ each element of the resulting array, for consistency, again, the
>> example.
>
>
> Inasmuch as we don't understand the reasoning behind how your proposal
> partitions the input value, providing a coherent name for those parts is a
> non-starter. Again, why does your proposal treat *some* zeros different
> from non-zero digits in the same position, or different from previous or
> subsequent zeros encountered within the number?
>
> I mean, this proposal is as DOA as any I've ever encountered on here, but
> that question is haunting me!
>
> Otherwise, you have only offered standard western academic conjecture,
>> which can be set aside where an individual is not beholden to or reliant on
>> western academic conjecture to proceed with anything they decide to.
>
>
> As evidenced by my persistence in this thread, I don't count myself among
> them, but a significant share of the best minds in JavaScript are on this
> mailing list, and it seems that not a single person can make sense of this
> proposal. As we are on the topic of math, I would urge you to consider the
> common denominator, and it isn't "western academic conjecture"(??!).
>
> And with that, I think I had better let this rest.
>
> On Tue, Mar 12, 2019 at 12:54 PM guest271314 <guest271...@gmail.com>
> wrote:
>
>> That's the premise that I'm challenging. Why is it simpler, and how does
>>> it, *in any appreciable way*, improve upon whatever you're asserting is
>>> "broken"?
>>
>>
>> The same way that Intl.NumberFormat.prototype.formatToParts does. Though
>> takes the concept one step further by *spreading* each digit to an
>> array. If the number has a decimal, the decimal portion is set at a single
>> element of an array. If the decimal begins with a 0, continue until the
>> first non-zero number is reached, include that number in the decimal
>> portion within the array, and the remainder of the decimal portion is
>> spread to remainder of array elements
>>
>> Example:
>>
>> var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
>> arrayToNumber(n); // 100.00015
>>
>> The proposal improves what is broken by not returning broken results
>> relevant to decimal numbers. The proposal allows users to get and set any
>> portion of a number using indexes of an array, which can then be converted
>> back to a number.
>>
>> If you are failing to interpret that as useful, that is your own issue.
>> You might as well state that Intl.NumberFormat.prototype.formatToParts does
>> not have any use. And further, JavaScript number implementation is fine
>> just the way that it is currently implemented, unless *you *decide that
>> any proposal is useful.
>>
>> The array format is a simple data structure. Can be converted to JSON;
>> can be extended to include a description of each digit that is a user gets
>> or sets; e.g.,
>>
>> n[0].description // {digit: 1, place: 'hundreds', decimalSibling:
>> true, ...etc.}
>>
>> With respect, your test cases confuse the issue more than they clarify.
>>> Questions on how you'd use this structure aside (which are still
>>> important), your test cases *don't actually produce a structure in
>>> which digits are accessible by nth index* (e.g., the 0-grouping
>>> behavior).
>>
>>
>> Not sure what you mean? What are you confused about relevant to the test
>> cases? The code at the OP includes 1) the original proof of concept; 2)
>> code by Stack Overflow user Shidersz
>> <https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs
>> in the original code. Yes, the code at the OP does produce the expected
>> result.
>>
>> You are misconstruing the proposal. The code already returns the expected
>> result. Do not ask for approval for anything. Just do and let the aftermath
>> settle to its own level.
>>
>> The proposal is asking you people who claim to be specification authors
>> to _name_ each element of the resulting array, for consistency, again, the
>> example
>>
>> var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
>>
>> as an array users obviously do not have additional data about the values
>> in the array. What do you call the 0 at index 1? What do you call the 5 at
>> index 4?
>>
>> Before incorporating the output into an object, similar to
>> Intl.NumberFormat.prototype.formatToParts - and including the original
>> array in the object, or Map - am asking for standardization of the names of
>> each digit in a _spread_ number in an array.
>>
>> Number to array, array to number is just the first part of the procedure.
>> The part relevant to actually _naming_ the parts, for disambiguation, is
>> what propose here. If you are not interested, that is fine. Do not
>> necessarily need you to do anything. Will do for self as have and continue
>> to do independently, and name the discrete portions of the number
>> arbitrarily, without your input.
>>
>> Again, if you do not gather that this proposal is similar to and extends
>> the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
>> should try to use that feature, note that "integer" and "fraction" and
>> "minusSign" are possible return values at output, then lobby for the
>> feature to be removed from Ecma specification, for the same reasons that
>> you are citing at this proposal, which would then make your
>>
>> premise that I'm challenging
>>
>>
>> consistent. Otherwise, you have only offered standard western academic
>> conjecture, which can be set aside where an individual is not beholden to
>> or reliant on western academic conjecture to proceed with anything they
>> decide to.
>>
>> With respect,
>>
>>
>> "respect" is irrelevant to the proposal. Do not need or care about what
>> you consider "respect". You cannot offend this user.
>>
>> On Tue, Mar 12, 2019 at 3:46 PM Jeremy Martin <jmar...@gmail.com> wrote:
>>
>>> The proposal seeks to standardize the naming conventions of number to
>>>> array and array to number, including decimals.
>>>
>>>
>>> You're describing the hammer. When we ask for the motivation for your
>>> proposal, we're trying to understand *what you want to do with the
>>> hammer*, and that needs to be something more generalized than
>>> programmatically recreating an interesting number sequence (and more
>>> explicitly stated than whatever we are to infer from your test cases).
>>>
>>> In our repeated attempts to suss that out, this seems to be your
>>> clearest description:
>>>
>>> It is simpler to have the ability to add, subtract, divide, or otherwise
>>>> manipulate individual nth indexes of an integer or decimal represented as
>>>> an array of integers potentially containing one decimal than trying to
>>>> perform the same mathematical operations on a number in JavaScript
>>>> (essentially broken in JavaScript due to the floating-point number issues).
>>>
>>>
>>> That's the premise that I'm challenging. Why is it simpler, and how does
>>> it, *in any appreciable way*, improve upon whatever you're asserting is
>>> "broken"? As specified by your proposal, your input and output parameters
>>> are Floats, which means that the precision limitations of floating point
>>> numbers remain unaddressed.
>>>
>>> All of the test cases used at the code which fixed the bugs in the proof
>>>> of concept at the original post output the expected result.
>>>
>>>
>>> With respect, your test cases confuse the issue more than they clarify.
>>> Questions on how you'd use this structure aside (which are still
>>> important), your test cases *don't actually produce a structure in
>>> which digits are accessible by nth index* (e.g., the 0-grouping
>>> behavior).
>>>
>>> On Tue, Mar 12, 2019 at 2:13 AM guest271314 <guest271...@gmail.com>
>>> wrote:
>>>
>>>> With respect, it's still not clear how you want to interact with the
>>>>> array of values once you've destructured a Float into your array format.
>>>>
>>>> If all you have is an array of single-digit numbers that represent the
>>>>> values in the tenths/hundredths/etc. positions of the source number, how
>>>>> does this actually circumvent the challenges of representing Decimal
>>>>> values
>>>>> that aren't exactly representable as a Float?
>>>>
>>>>
>>>> It is not clear how your examples of adding specific values in
>>>> JavaScript are relevant to the proposal.
>>>>
>>>> All of the test cases used at the code which fixed the bugs in the
>>>> proof of concept at the original post output the expected result.
>>>>
>>>> If you have more test cases, number or decimal, to suggest for input
>>>> relevant to the code at the original proposal, number to array, array to
>>>> number, kindly post those tests cases listing input and expected output.
>>>>
>>>> The proposal does not seek to solve all JavaScript number issues.
>>>>
>>>> The proposal seeks to standardize the naming conventions of number to
>>>> array and array to number, including decimals. An array is the simplest
>>>> form of structured output. An object of key, value pairs (similar to
>>>> Intl.NumberFormat, with JavaScript numbers instead of strings) can also be
>>>> utilized for each of the digits of integer and decimal (fraction), if any.
>>>>
>>>>
>>>>
>>>> On Mon, Mar 11, 2019 at 4:33 PM Jeremy Martin <jmar...@gmail.com>
>>>> wrote:
>>>>
>>>>> With respect, it's still not clear how you want to interact with the
>>>>> array of values once you've destructured a Float into your array format.
>>>>>
>>>>> If all you have is an array of single-digit numbers that represent the
>>>>> values in the tenths/hundredths/etc. positions of the source number, how
>>>>> does this actually circumvent the challenges of representing Decimal
>>>>> values
>>>>> that aren't exactly representable as a Float?
>>>>>
>>>>> To illustrate this challenge, let's use the classic example we've all
>>>>> seen hundreds of times:
>>>>>
>>>>> > .1 + .2
>>>>> 0.30000000000000004
>>>>>
>>>>> For a long time, all the reading I would do about *why* this produced
>>>>> a weird result would *sort* of make sense and *sort* of confuse me.
>>>>> That is, I could understand *why* 3/10ths isn't representable as a
>>>>> Float, but then I would get confused by the fact that I could type `.3`
>>>>> into a REPL, and it would *actually work *(??!):
>>>>>
>>>>> > .3
>>>>> 0.3
>>>>>
>>>>> I mean, who's lying? How come `.3` works fine when I just type it
>>>>> straight in, and `.1 + .3` works just fine, but there's just these
>>>>> specific cases like `.1 + .2` where all of a sudden `.3` decides not
>>>>> to be representable again?
>>>>>
>>>>> I admit this is conjecture, but maybe that's part of the confusion
>>>>> motivating this proposal? And maybe the idea is that if we can break `.1`
>>>>> and `.2` into some sort of an array structure (e.g., [0, 1] and [0,
>>>>> 2]), then we can add the individual parts as integers (giving us
>>>>> something like [0, 3]) which we can then just convert back into a
>>>>> single numeric value at the end as 0.3, and voila, no
>>>>> 0.30000000000000004 shenanigans?
>>>>>
>>>>> The problem is that this all builds on a fundamental misunderstanding
>>>>> of what's going. Let's revisit the basic example of entering a value into
>>>>> the REPL:
>>>>>
>>>>> > .3
>>>>> 0.3
>>>>>
>>>>> This, as I stated earlier, contributed greatly to my own hangups in
>>>>> understanding what was going on here. What I personally didn't understand
>>>>> was that the `0.3` value you see above isn't actually the *Decimal*
>>>>> value 0.3. It's just a *very* close approximation of 0.3. (so close,
>>>>> in fact, that 0.3 is the *closest* Decimal value that it can be
>>>>> rounded to, so that's what gets emitted).
>>>>>
>>>>> So, going back to our earlier example, why do we get a *different*
>>>>> output when we're dealing with the result of a mathematical operation, as
>>>>> opposed to getting the *same* very close approximation of 0.3 that we
>>>>> get when we simply type it into the REPL?
>>>>>
>>>>> > .1 + .2
>>>>> 0.30000000000000004
>>>>>
>>>>> The answer lies in the fact that 0.1 and 0.2 *also* can't be
>>>>> represented exactly as Floats. Just like we saw with 0.3, we can type them
>>>>> into the REPL and see a value that looks the exact same being emitted back
>>>>> at us:
>>>>>
>>>>> > .1
>>>>> 0.1
>>>>> > .2
>>>>> 0.2
>>>>>
>>>>> ...but also like we saw with 0.3, they only *look* like accurate
>>>>> representations. Once again, 0.1 and 0.2 are just the closest Decimal
>>>>> values that the underlying Float values can be rounded to for display.
>>>>>
>>>>> This rounding behavior, then, is what causes us to get
>>>>> 0.30000000000000004 when we add them together, because the *slight*
>>>>> rounding error with 0.1 and the *slight* rounding error with 0.2
>>>>> compound to result in a Float that no longer rounds closer to 0.3, and
>>>>> instead closer to the "wrong" Decimal value that we see emitted before.
>>>>>
>>>>> It's worth noting that this same behavior applies to, e.g., 0.1 +
>>>>> 0.3, even though that *looks* like it produces the correct result of
>>>>> 0.4. In reality, however, this is just a case where the rounding
>>>>> errors have the effect of (almost) canceling each other out, such that the
>>>>> resulting Float rounds closer to 0.4 than any other value for display
>>>>> purposes (despite being only negligibly more accurate than our
>>>>> 0.30000000000000004 result was).
>>>>>
>>>>> Ok, so why am I trying to explain all this? Because I'm trying to
>>>>> illustrate why it sounds like this proposal doesn't actually solve the
>>>>> problem that you want it to. Is it possible to standardize a system for
>>>>> transformations and math operations like the following?
>>>>>
>>>>> const arg1 = numberToArray(0.1) // [0, 1]
>>>>> const arg2 = numberToArray(0.2) // [0, 2]
>>>>>
>>>>> const arraySum = addArrayNumbers(arg1, arg2) // [0, 3]
>>>>>
>>>>> const result = arrayToNumber(arraySum) // 0.3
>>>>>
>>>>> Sure, and at the very end, you actually get a value that *looks* right
>>>>> (0.3, yay!). But *it's still not actually 0.3.* So what become the
>>>>> motivation for this? You have a solution that, in terms of memory and CPU
>>>>> cycles, is orders of magnitude more costly to calculate than `0.1 +
>>>>> 0.2` as a plain JavaScript expression, and in return you get a result
>>>>> that is, *at best*, infinitesimally more accurate than the
>>>>> alternative when carried all the way out to the quadrillionths place or
>>>>> greater.
>>>>>
>>>>> Do you actually have a use case for mathematical operations that are
>>>>> fault tolerant enough to represent Decimal values as Floats, but that
>>>>> fault
>>>>> tolerance is sensitive to very, very specific rounding behavior at the
>>>>> quadrillionths level? I can't even imagine what that use case would be.
>>>>>
>>>>> On Mon, Mar 11, 2019 at 10:06 AM guest271314 <guest271...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> JS numbers are specified to be in terms of IEEE-754 doubles, so
>>>>>>> tenths, hundredths, and so on cannot be precisely represented. [1] So
>>>>>>> there
>>>>>>> is no way to increase precision here beyond the above that Tab showed,
>>>>>>> assuming each of those operations are accurate to the bit.
>>>>>>
>>>>>>
>>>>>> Not sure what the message is trying to convey? The code at the first
>>>>>> post already overcomes the issue of
>>>>>>
>>>>>> i % 1 // 0.5670000000000073
>>>>>>
>>>>>> described by Tab. All of the input numbers are converted to array
>>>>>> then back to number without losing any precision or adding more numbers
>>>>>> to
>>>>>> the input.
>>>>>>
>>>>>> The proposal suggests that each discrete digit of any number a user
>>>>>> can get and set and be clearly defined with a consistent name, or
>>>>>> reference. Converting the number to an array is a simple means of
>>>>>> processing each digit independently.
>>>>>>
>>>>>> On Mon, Mar 11, 2019 at 10:41 AM Isiah Meadows <
>>>>>> isiahmead...@gmail.com> wrote:
>>>>>>
>>>>>>> JS numbers are specified to be in terms of IEEE-754 doubles, so
>>>>>>> tenths, hundredths, and so on cannot be precisely represented. [1] So
>>>>>>> there
>>>>>>> is no way to increase precision here beyond the above that Tab showed,
>>>>>>> assuming each of those operations are accurate to the bit.
>>>>>>>
>>>>>>> [1]:
>>>>>>> https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/
>>>>>>> On Sun, Mar 10, 2019 at 13:26 guest271314 <guest271...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> So this would help with precision?
>>>>>>>>
>>>>>>>>
>>>>>>>> To an appreciable degree, yes, without the scope of JavaScript
>>>>>>>> floating-point number implementation.
>>>>>>>>
>>>>>>>> The gist of the proposal is to formalize, standardize, or whatever
>>>>>>>> term specification writers want to use, the *naming* of each method or
>>>>>>>> operation which can get and set each discrete digit of a number -
>>>>>>>> without
>>>>>>>> using String methods.
>>>>>>>>
>>>>>>>> For input
>>>>>>>>
>>>>>>>> 1234.567
>>>>>>>>
>>>>>>>> Each digit has a formal name which developers can get and set,
>>>>>>>> whether in an array, object or number format.
>>>>>>>>
>>>>>>>> On Sun, Mar 10, 2019 at 5:17 PM Michael Theriot <
>>>>>>>> michael.lee.ther...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> So this would help with precision?
>>>>>>>>>
>>>>>>>>> On Sunday, March 10, 2019, guest271314 <guest271...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> (If you really wanted this as an integer, it's not well-founded;
>>>>>>>>>>> .567
>>>>>>>>>>> isn't exactly representable as a double, so JS doesn't know that
>>>>>>>>>>> you
>>>>>>>>>>> "meant" it to have only three digits after the decimal point,
>>>>>>>>>>> and thus
>>>>>>>>>>> want 567 as the answer. You'll instead get some very very large
>>>>>>>>>>> integer that *starts with* 567, followed by a bunch of zeros,
>>>>>>>>>>> followed
>>>>>>>>>>> by some randomish digits at the end.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The code at the first post solves that problem.
>>>>>>>>>>
>>>>>>>>>> But the question is still "what would someone use this
>>>>>>>>>>> information for?"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That question has been answered several times in the posts above.
>>>>>>>>>> This users' motivation was and is the ability to manipulate
>>>>>>>>>> JavaScript
>>>>>>>>>> floating-point numbers (which could be considered "broken", as you
>>>>>>>>>> described above) in order to solve mathematical problems (in this
>>>>>>>>>> case,
>>>>>>>>>> directly calculating the *n*th lexicographic permutation) with
>>>>>>>>>> the number or decimal being represented as an array, without having
>>>>>>>>>> to be
>>>>>>>>>> concerned with not getting the same value when the array is
>>>>>>>>>> converted back
>>>>>>>>>> to a number.
>>>>>>>>>>
>>>>>>>>>> Felipe Nascimento de Moura mentioned several other applications.
>>>>>>>>>>
>>>>>>>>>> The work has already been done. This proposal is essentially to
>>>>>>>>>> standardize the naming conventions. Whether a Number method is used
>>>>>>>>>>
>>>>>>>>>> i.getTensMethod
>>>>>>>>>>
>>>>>>>>>> or an array is used
>>>>>>>>>>
>>>>>>>>>> arr["integer"] // 1234
>>>>>>>>>>
>>>>>>>>>> or an object where values are arrays is used
>>>>>>>>>>
>>>>>>>>>> o["fraction"] // .567
>>>>>>>>>>
>>>>>>>>>> Having mentioned Intl.NumberFormat earlier in the thread, if the
>>>>>>>>>> issue devoting resources to a *new *proposal, Intl.NumberFormate
>>>>>>>>>> can be extended; e.g. a rough draft in code
>>>>>>>>>>
>>>>>>>>>> function formatNumberParts(args) {
>>>>>>>>>> return Object.assign({sign:0, fraction:[0], integer:[0]},
>>>>>>>>>> ...args.filter(({type}) => type === "integer" || type === "fraction"
>>>>>>>>>> ||
>>>>>>>>>> type === "minusSign").map(({type, value}) => ({[type === "minusSign"
>>>>>>>>>> ?
>>>>>>>>>> "sign" : type]: type !== "minusSign" ? [...value].map(Number) :
>>>>>>>>>> -1})));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> let number = -123;
>>>>>>>>>>
>>>>>>>>>> let formatter = new Intl.NumberFormat('en-US');
>>>>>>>>>>
>>>>>>>>>> let res = formatter.formatToParts(number);
>>>>>>>>>>
>>>>>>>>>> formatNumberParts(res);
>>>>>>>>>>
>>>>>>>>>> If the concern is that the proposal would not be useful, consider
>>>>>>>>>> what you would *name* various uses of Math.trunc and remainder
>>>>>>>>>> operator used at your message?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Mar 10, 2019 at 3:58 PM Tab Atkins Jr. <
>>>>>>>>>> jackalm...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Sat, Mar 9, 2019 at 11:10 AM Felipe Nascimento de Moura
>>>>>>>>>>> <felipenmo...@gmail.com> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Personally, I don't think it would be THAT useful...
>>>>>>>>>>> > but...I think there is something behind this proposal that
>>>>>>>>>>> makes sense.
>>>>>>>>>>> >
>>>>>>>>>>> > I do believe it could be useful for developers to have an
>>>>>>>>>>> easier access to number parts or characteristics.
>>>>>>>>>>> > Perhaps something like:
>>>>>>>>>>> >
>>>>>>>>>>> > const i = 1234.567;
>>>>>>>>>>>
>>>>>>>>>>> Can you provide a scenario in which these would do something
>>>>>>>>>>> useful,
>>>>>>>>>>> such that it would be worth adding them over just using the math
>>>>>>>>>>> operations that already exist?
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.float ); // 567
>>>>>>>>>>>
>>>>>>>>>>> i % 1
>>>>>>>>>>>
>>>>>>>>>>> (If you really wanted this as an integer, it's not well-founded;
>>>>>>>>>>> .567
>>>>>>>>>>> isn't exactly representable as a double, so JS doesn't know that
>>>>>>>>>>> you
>>>>>>>>>>> "meant" it to have only three digits after the decimal point,
>>>>>>>>>>> and thus
>>>>>>>>>>> want 567 as the answer. You'll instead get some very very large
>>>>>>>>>>> integer that *starts with* 567, followed by a bunch of zeros,
>>>>>>>>>>> followed
>>>>>>>>>>> by some randomish digits at the end.)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.abs ); // 1234
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.thousands ); // 1
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i / 1000)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.million ); // 0
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i / 1e6)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.hundred ); // 2
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i / 100) % 10
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.hundreds ); // 12
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i / 100)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.ten ); // 2
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i / 10) % 10
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.tens ); // 123
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i / 10)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.tenth ); // 5
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i % 1 * 10) % 10
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.tenths ); // 5
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i % 1 * 10)
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.hundredth ); // 6
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i % 1 * 100) % 10
>>>>>>>>>>>
>>>>>>>>>>> > console.log( i.hundredths ); // 56
>>>>>>>>>>>
>>>>>>>>>>> Math.trunc(i % 1 * 100)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Some of these are easy to remember and use; others take some
>>>>>>>>>>> thinking
>>>>>>>>>>> to deploy. But the question is still "what would someone use this
>>>>>>>>>>> information for?", such that the benefit to developers is worth
>>>>>>>>>>> the
>>>>>>>>>>> cost to all parties involved (spec writers, implementors,
>>>>>>>>>>> testers, and
>>>>>>>>>>> then developers having to navigate a larger stdlib).
>>>>>>>>>>>
>>>>>>>>>>> ~TJ
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>> es-discuss@mozilla.org
>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>> es-discuss mailing list
>>>>>>>>> es-discuss@mozilla.org
>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> es-discuss mailing list
>>>>>>>> es-discuss@mozilla.org
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeremy Martin
>>>>> 661.312.3853
>>>>> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>>>>>
>>>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>>>
>>>
>
> --
> Jeremy Martin
> 661.312.3853
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
