Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #40225 > unrolled thread

Decimal numeric string to hexadecimal numeric string?

Back to article view | Back to comp.lang.javascript

Contents

  Decimal numeric string to hexadecimal numeric string? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-06-17 14:28 -0700
    Re: Decimal numeric string to hexadecimal numeric string? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-06-17 21:38 -0700
      Re: Decimal numeric string to hexadecimal numeric string? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-06-19 00:39 -0700
    Re: Decimal numeric string to hexadecimal numeric string? Scott Sauyet <scott@sauyet.com> - 2021-06-18 05:59 -0700
      Re: Decimal numeric string to hexadecimal numeric string? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-06-19 00:45 -0700
        Re: Decimal numeric string to hexadecimal numeric string? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-19 11:42 +0100
          Re: Decimal numeric string to hexadecimal numeric string? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-07-01 00:51 +0200
            Re: Decimal numeric string to hexadecimal numeric string? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-06-30 17:39 -0700
              Re: Decimal numeric string to hexadecimal numeric string? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-01 01:50 +0100
                Re: Decimal numeric string to hexadecimal numeric string? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-07-01 12:46 +0200
              Re: Decimal numeric string to hexadecimal numeric string? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-07-01 12:43 +0200

#40225 — Decimal numeric string to hexadecimal numeric string?

prgNbr="11"

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

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

[toc] | [next] | [standalone]

#40227

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>

[toc] | [prev] | [next] | [standalone]

#40231

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.

[toc] | [prev] | [next] | [standalone]

#40229

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

[toc] | [prev] | [next] | [standalone]

#40232

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.

[toc] | [prev] | [next] | [standalone]

#40233

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.

[toc] | [prev] | [next] | [standalone]

#40272

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.

[toc] | [prev] | [next] | [standalone]

#40273

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)

[toc] | [prev] | [next] | [standalone]

#40274

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

[toc] | [prev] | [next] | [standalone]

#40278

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.

[toc] | [prev] | [next] | [standalone]

#40277

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web