<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?</blockquote><div><br></div><div>It is not clear how your examples of adding specific values in JavaScript are relevant to the proposal. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>The proposal does not seek to solve all JavaScript number issues. </div><div><br></div><div>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.</div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 4:33 PM Jeremy Martin <<a href="mailto:jmar777@gmail.com">jmar777@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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.<div><br></div><div>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?</div><div><br></div><div>To illustrate this challenge, let's use the classic example we've all seen hundreds of times:</div><div><div><font face="monospace, monospace"><br class="gmail-m_8395220853052978618gmail-Apple-interchange-newline">> .1 + .2</font></div><div><font face="monospace, monospace">0.30000000000000004</font></div></div><div><br></div><div>For a long time, all the reading I would do about <i>why</i> this produced a weird result would <i>sort</i> of make sense and <i>sort</i> of confuse me. That is, I could understand <i>why</i> 3/10ths isn't representable as a Float, but then I would get confused by the fact that I could type `<font face="monospace, monospace">.3</font>` into a <font face="arial, helvetica, sans-serif">REP</font>L, and it would <i>actually work </i>(??!):</div><div><br></div><div><font face="monospace, monospace">> .3</font></div><div><font face="monospace, monospace">0.3</font></div><div><br></div><div>I mean, who's lying? How come `<font face="monospace, monospace">.3</font>` works fine when I just type it straight in, and `<font face="monospace, monospace">.1 + .3</font>` works just fine, but there's just these specific cases like `<font face="monospace, monospace">.1 + .2</font>` where all of a sudden `<font face="monospace, monospace">.3</font>` decides not to be representable again?</div><div><br></div><div>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., <font face="monospace, monospace">[0, 1]</font> and <font face="monospace, monospace">[0, 2]),</font><font face="arial, helvetica, sans-serif"> then we can add the individual parts as integers (giving us something like </font><span style="font-family:monospace,monospace">[0, 3])</span><span style="font-family:arial,helvetica,sans-serif"> which we can then just convert back into a single numeric value at the end as </span><font face="monospace, monospace">0.3</font><span style="font-family:arial,helvetica,sans-serif">, and voila, no </span><span style="font-family:monospace,monospace">0.30000000000000004</span><span style="font-family:arial,helvetica,sans-serif"> shenanigans?</span></div><div><br></div><div>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:</div><div><br></div><div><div><font face="monospace, monospace">> .3</font></div><div><font face="monospace, monospace">0.3</font></div></div><div><br></div><div>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 `<font face="monospace, monospace">0.3</font>` value you see above isn't actually the <i>Decimal</i> value 0.3. It's just a <i>very</i> close approximation of 0.3. (so close, in fact, that 0.3 is the <i>closest</i> Decimal value that it can be rounded to, so that's what gets emitted).</div><div><br></div><div>So, going back to our earlier example, why do we get a <i>different</i> output when we're dealing with the result of a mathematical operation, as opposed to getting the <i>same</i> very close approximation of 0.3 that we get when we simply type it into the REPL?<br><br><div><font face="monospace, monospace">> .1 + .2</font></div><div><font face="monospace, monospace">0.30000000000000004</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">The answer lies in the fact that 0.1 and 0.2 <i>also</i> 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:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><div><font face="monospace, monospace">> .1</font></div><div><font face="monospace, monospace">0.1</font></div></div><div><div><font face="monospace, monospace">> .2</font></div><div><font face="monospace, monospace">0.2</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">...but also like we saw with 0.3, they only <i>look</i> 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.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">This rounding behavior, then, is what causes us to get </font><font face="monospace, monospace">0.30000000000000004</font><font face="arial, helvetica, sans-serif"> when we add them together, because the <i>slight</i> rounding error with 0.1 and the <i>slight</i> 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.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">It's worth noting that this same behavior applies to, e.g., </font><font face="monospace, monospace">0.1 + 0.3, </font><font face="arial, helvetica, sans-serif">even though that <i>looks</i> like it produces the correct result of </font><font face="monospace, monospace">0.4</font><font face="arial, helvetica, sans-serif">. 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 </font><font face="monospace, monospace">0.4</font><font face="arial, helvetica, sans-serif"> than any other value for display purposes (despite being only negligibly more accurate than our 0.30000000000000004 result was).</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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?</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="monospace, monospace">  const arg1 = numberToArray(0.1) // [0, 1]</font></div><div><font face="monospace, monospace">  const arg2 = numberToArray(0.2) // [0, 2]</font></div><div><font face="monospace, monospace">  </font></div><div><font face="monospace, monospace">  const arraySum = addArrayNumbers(arg1, arg2) // [0, 3]</font></div><div><font face="monospace, monospace">  </font></div><div><font face="monospace, monospace">  const result = arrayToNumber(arraySum) // 0.3</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Sure, and at the very end, you actually get a value that <i>looks</i> right (</font><font face="monospace, monospace">0.3</font><font face="arial, helvetica, sans-serif">, yay!). But <i><b>it's still not actually 0.3</b>.</i> 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 `</font><font face="monospace, monospace">0.1 + 0.2</font><font face="arial, helvetica, sans-serif">` as a plain JavaScript expression, and in return you get a result that is, <i>at best</i>, infinitesimally more accurate than the alternative when carried all the way out to the quadrillionths place or greater.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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.</font></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 10:06 AM guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>Not sure what the message is trying to convey?  The code at the first post already overcomes the issue of</div><div><br></div><div>    <span style="background-color:transparent;color:inherit;font-family:Menlo,Monaco,Consolas,"Courier New",monospace;font-size:14px;white-space:pre-wrap">i % 1 // 0.5670000000000073</span></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 10:41 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br><br>[1]: <a href="https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/" target="_blank">https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/</a><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 13:26 guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So this would help with precision?</blockquote><div><br></div><div>To an appreciable degree, yes, without the scope of JavaScript floating-point number implementation. </div><div><br></div><div>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. </div><div><br></div><div>For input </div><div><br></div><div>    1234.567</div><div><br></div><div>Each digit has a formal name which developers can get and set, whether in an array, object or number format. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 5:17 PM Michael Theriot <<a href="mailto:michael.lee.theriot@gmail.com" target="_blank">michael.lee.theriot@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>So this would help with precision?<br></div><br>On Sunday, March 10, 2019, guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(If you really wanted this as an integer, it's not well-founded; .567<br>isn't exactly representable as a double, so JS doesn't know that you<br>"meant" it to have only three digits after the decimal point, and thus<br>want 567 as the answer. You'll instead get some very very large<br>integer that *starts with* 567, followed by a bunch of zeros, followed<br>by some randomish digits at the end.)</blockquote><div><br></div><div>The code at the first post solves that problem. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But the question is still "what would someone use this information for?"</blockquote><div><br></div><div>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 <i>n</i>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. </div><div><br></div>Felipe Nascimento de Moura mentioned several other applications. <div><br></div><div>The work has already been done. This proposal is essentially to standardize the naming conventions. Whether a Number method is used </div><div><br></div><div>    i.getTensMethod</div><div><br></div><div>or an array is used</div><div><br></div><div>   arr["integer"] // 1234</div><div><br></div><div>or an object where values are arrays is used</div><div><br></div><div>    o["fraction"] // .567<br><div> </div><div>Having mentioned Intl.NumberFormat earlier in the thread, if the issue devoting resources to a <i>new </i>proposal, Intl.NumberFormate can be extended; e.g. a rough draft in code</div></div><div><br></div><div><div>    function formatNumberParts(args) {</div><div>      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})));</div><div>    }</div><div><br></div><div>    let number = -123;</div><div><br></div><div>    let formatter = new Intl.NumberFormat('en-US');</div><div><br></div><div>    let res = formatter.formatToParts(number);</div><div><br></div><div>    formatNumberParts(res);</div></div><div><br></div><div>If the concern is that the proposal would not be useful, consider what you would <i>name</i> various uses of Math.trunc and remainder operator used at your message?</div><div>    </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 3:58 PM Tab Atkins Jr. <<a href="mailto:jackalmage@gmail.com" target="_blank">jackalmage@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Mar 9, 2019 at 11:10 AM Felipe Nascimento de Moura<br>
<<a href="mailto:felipenmoura@gmail.com" target="_blank">felipenmoura@gmail.com</a>> wrote:<br>
><br>
> Personally, I don't think it would be THAT useful...<br>
> but...I think there is something behind this proposal that makes sense.<br>
><br>
> I do believe it could be useful for developers to have an easier access to number parts or characteristics.<br>
> Perhaps something like:<br>
><br>
> const i = 1234.567;<br>
<br>
Can you provide a scenario in which these would do something useful,<br>
such that it would be worth adding them over just using the math<br>
operations that already exist?<br>
<br>
> console.log( i.float ); // 567<br>
<br>
i % 1<br>
<br>
(If you really wanted this as an integer, it's not well-founded; .567<br>
isn't exactly representable as a double, so JS doesn't know that you<br>
"meant" it to have only three digits after the decimal point, and thus<br>
want 567 as the answer. You'll instead get some very very large<br>
integer that *starts with* 567, followed by a bunch of zeros, followed<br>
by some randomish digits at the end.)<br>
<br>
> console.log( i.abs ); // 1234<br>
<br>
Math.trunc(i)<br>
<br>
> console.log( i.thousands ); // 1<br>
<br>
Math.trunc(i / 1000)<br>
<br>
> console.log( i.million ); // 0<br>
<br>
Math.trunc(i / 1e6)<br>
<br>
> console.log( i.hundred ); // 2<br>
<br>
Math.trunc(i / 100) % 10<br>
<br>
> console.log( i.hundreds ); // 12<br>
<br>
Math.trunc(i / 100)<br>
<br>
> console.log( i.ten ); // 2<br>
<br>
Math.trunc(i / 10) % 10<br>
<br>
> console.log( i.tens ); // 123<br>
<br>
Math.trunc(i / 10)<br>
<br>
> console.log( i.tenth ); // 5<br>
<br>
Math.trunc(i % 1 * 10) % 10<br>
<br>
> console.log( i.tenths ); // 5<br>
<br>
Math.trunc(i % 1 * 10)<br>
<br>
> console.log( i.hundredth ); // 6<br>
<br>
Math.trunc(i % 1 * 100) % 10<br>
<br>
> console.log( i.hundredths ); // 56<br>
<br>
Math.trunc(i % 1 * 100)<br>
<br>
<br>
Some of these are easy to remember and use; others take some thinking<br>
to deploy. But the question is still "what would someone use this<br>
information for?", such that the benefit to developers is worth the<br>
cost to all parties involved (spec writers, implementors, testers, and<br>
then developers having to navigate a larger stdlib).<br>
<br>
~TJ<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</blockquote>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_8395220853052978618gmail_signature"><div dir="ltr"><div>Jeremy Martin<br>661.312.3853</div><div><div><a href="https://twitter.com/jmar777" target="_blank">@jmar777</a> / <a href="https://stream.live/j" target="_blank">@j</a></div><br></div></div></div>
</blockquote></div>