• #### Decimal numeric string to hexadecimal numeric string?

From =?UTF-8?Q?Jonas_Th=C3=B6rnvall?=@21:1/5 to All on Thu Jun 17 14:28:52 2021
prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

Is there a faster direct way to do the two last steps?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Michael Haufe (TNO)@21:1/5 to jonas.t...@gmail.com on Thu Jun 17 21:38:30 2021
On Thursday, June 17, 2021 at 4:28:57 PM UTC-5, jonas.t...@gmail.com wrote:
prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

Is there a faster direct way to do the two last steps?

parseInt(prgNbr,16)

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Scott Sauyet@21:1/5 to Jonas Thornvall on Fri Jun 18 05:59:17 2021
Jonas Thornvall wrote:

prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

Is there a faster direct way to do the two last steps?

It might help if you told us what that was supposed to do, as it's not
working code.

If you want to parse `11` as though it is a hexadecimal string and
thus should return the number 17, there's one answer. If you want
to return the hexadecimal equivalent of the decimal number 11, namely
`b`, then there's a different answer.

What are you trying to do?

-- Scott

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From =?UTF-8?Q?Jonas_Th=C3=B6rnvall?=@21:1/5 to All on Sat Jun 19 00:39:27 2021
fredag 18 juni 2021 kl. 06:38:35 UTC+2 skrev Michael Haufe (TNO):
On Thursday, June 17, 2021 at 4:28:57 PM UTC-5, jonas.t...@gmail.com wrote:
prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

Is there a faster direct way to do the two last steps?
parseInt(prgNbr,16)

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt>
Great suggestion Michael had no idea parseInt had base as parameter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From =?UTF-8?Q?Jonas_Th=C3=B6rnvall?=@21:1/5 to All on Sat Jun 19 00:45:32 2021
fredag 18 juni 2021 kl. 14:59:24 UTC+2 skrev sc...@sauyet.com:
Jonas Thornvall wrote:

prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

Is there a faster direct way to do the two last steps?
It might help if you told us what that was supposed to do, as it's not working code.

If you want to parse `11` as though it is a hexadecimal string and
thus should return the number 17, there's one answer. If you want
to return the hexadecimal equivalent of the decimal number 11, namely
`b`, then there's a different answer.

What are you trying to do?

-- Scott
A numeric "decimal" string to hexdecimal string.
So Michales suggestion did not work out, it gives a hexadecimal number not string.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Ben Bacarisse@21:1/5 to jonas.thornvall@gmail.com on Sat Jun 19 11:42:16 2021
Jonas Thörnvall <jonas.thornvall@gmail.com> writes:

fredag 18 juni 2021 kl. 14:59:24 UTC+2 skrev sc...@sauyet.com:
Jonas Thornvall wrote:

prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

What are you trying to do?

A numeric "decimal" string to hexdecimal string.
So Michales suggestion did not work out, it gives a hexadecimal number
not string.

parseInt(prgNbr).toString(16)

Technically, parseInt(prgNbr, 16) doesn't give a hexadecimal number
(there is not such thing). It gives a number by interpreting the string
as hexadecimal digits.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Thomas 'PointedEars' Lahn@21:1/5 to Ben Bacarisse on Thu Jul 1 00:51:08 2021
Ben Bacarisse wrote:

Jonas ThĂ¶rnvall <jonas.thornvall@gmail.com> writes:
fredag 18 juni 2021 kl. 14:59:24 UTC+2 skrev sc...@sauyet.com:
Jonas Thornvall wrote:
prgNbr="11"

parseInt(prgNbr);
prgNbr.toInteger(16);

Neither of these statements do anything useful as the argument is a
primitive value that cannot be modified.

What are you trying to do?

A numeric "decimal" string to hexdecimal string.
So Michales suggestion did not work out, it gives a hexadecimal number
not string.

parseInt(prgNbr).toString(16)

Technically, parseInt(prgNbr, 16) doesn't give a hexadecimal number
(there is not such thing). It gives a number by interpreting the string
as hexadecimal digits.

Instead:

let hex = parseInt(prgNbr, 10).toString(16);

parseInt() should not be called without a radix value because then the interpretation of the string depends on its prefix. This is a FAQ.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Ben Bacarisse@21:1/5 to tno@thenewobjective.com on Thu Jul 1 01:50:05 2021
"Michael Haufe (TNO)" <tno@thenewobjective.com> writes:

On Wednesday, June 30, 2021 at 5:51:16 PM UTC-5, Thomas 'PointedEars' Lahn wrote:

parseInt() should not be called without a radix value because then the
interpretation of the string depends on its prefix. This is a FAQ.

The FAQ should be updated. This now depends on the browser version.

With the following:

parseInt("070")

I see these results:

Brave (Chromium 91): 70
Firefox : 89: 70
IE 11: 70
IE 10: 70
IE 9: 70
IE 8: 56
IE 7: 56
IE 5: 56

But parseInt("0x70") should be 112 (and it is where I was able to test
it). I don't know if you are specifically talking about the 0 prefix
(not specified in ECMA-262) or about prefixes in general.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Michael Haufe (TNO)@21:1/5 to Thomas 'PointedEars' Lahn on Wed Jun 30 17:39:18 2021
On Wednesday, June 30, 2021 at 5:51:16 PM UTC-5, Thomas 'PointedEars' Lahn wrote:

parseInt() should not be called without a radix value because then the interpretation of the string depends on its prefix. This is a FAQ.

The FAQ should be updated. This now depends on the browser version.

With the following:

parseInt("070")

I see these results:

Brave (Chromium 91): 70
Firefox : 89: 70
IE 11: 70
IE 10: 70
IE 9: 70
IE 8: 56
IE 7: 56
IE 5: 56

<https://codepen.io/mlhaufe/pen/jOmERVg?editors=1000>

(When testing on older browsers use the debug view)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Thomas 'PointedEars' Lahn@21:1/5 to Ben Bacarisse on Thu Jul 1 12:46:24 2021
Ben Bacarisse wrote:

[â€¦] I don't know if you are specifically talking about the 0 prefix
(not specified in ECMA-262) [â€¦]

The triggering â€ś0â€ť prefix *was* specified in ECMA-262 until including Edition 3, but the behavior was specified as implementation-dependent.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Thomas 'PointedEars' Lahn@21:1/5 to All on Thu Jul 1 12:43:53 2021
Michael Haufe (TNO) wrote:

On Wednesday, June 30, 2021 at 5:51:16 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
parseInt() should not be called without a radix value because then the
interpretation of the string depends on its prefix. This is a FAQ.

The FAQ should be updated.

I am still waiting for, and am looking forward to, your pull requests
*shrug*

<https://github.com/PointedEars/FAQ-cljs>

This now depends on the browser version.

Not really, see below.

With the following:

parseInt("070")

I see these results:

Brave (Chromium 91): 70
Firefox : 89: 70
IE 11: 70
IE 10: 70
IE 9: 70
IE 8: 56
IE 7: 56
IE 5: 56

<https://codepen.io/mlhaufe/pen/jOmERVg?editors=1000>

(When testing on older browsers use the debug view)

The interpretation of octal string literals by parseInt() without â€śradixâ€ť argument *always* depended on the "browser version", more precisely the ECMAScript implementation supported, and the version of the script engine
used, by the runtime environment. That is *the* reason why the FAQ
recommends to specify the â€śradixâ€ť argument since time immemorial:

<http://PointedEars.de/scripts/faq/cljs/#parseIntBase>

Compare

<https://www.ecma-international.org/wp-content/uploads/ECMA-262_3rd_edition_december_1999.pdf#page=89>

with

<https://www.ecma-international.org/wp-content/uploads/ECMA-262_5th_edition_december_2009.pdf#page=114>

Microsoft Internet Explorer/MSHTML 5.0 through 8.0 support/use Microsoft JScript 5.0 through 5.8.x which implement ECMAScript Ed. 3/5.xÂą; whereas IE/MSHTML 9 and 10 support/use JScript 9.0 and 10.0.x, which implement ECMAScript Ed. 5.x.

The latest version of Firefox supports Mozilla JavaScript 78 and later
(I have only Firefox 78 here), and uses a recent version of Mozilla SpiderMonkey, which implements ECMAScript 2020 or later.

Chromium 91 supports Google JavaScript 9.0.257.29 or later, and uses Google
V8, which implements ECMAScript 2020 or later.

So your results are unsurprising (but valuableÂ˛) to me. See also:

<http://PointedEars.de/es-matrix#version-info>

BTW, it is July in Europe now, so ECMAScript 2021 was "released" :-o

<https://262.ecma-international.org/>

_______
Âą Here we can see that an ECMAScript implementation does not always meet
what is unambiguously specified in the Edition that it claims to
implement.
Â˛ Strangely enough, I do not have a test case for that in the ECMAScript
Support Matrix yet: <http://PointedEars.de/es-matrix/?filter=parseInt>
--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)