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)

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)

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)

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)

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)

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)

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)

"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)

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)

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)

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)