It is not obsolete, it can be useful in some cases. This code was probably written a long time ago.

fixed

The implication is that the library is available in the language you are being tested in. My point is that, providing the library name in the instructions is irrelevant to the solution if it is not actually provided. Possibly a purposeful misdirect, but that is a bit much for an 8kyu.

in C#

Not sure who is marking this as "best practice", but it is certainly not.

Just because you failed to use parseInt to do the conversion directly doesn't mean it's my fault for that.

I feel like we're talking in circles. I never even implied that it was your fault. Let me try to be more clear. I didn't use parseInt because JavaScript's parseInt will not convert this "0.db9318c2259923d0" (or any other form of string or literal hex fraction) to this 0.857713 (or any other decimal fraction). JavaScript has no concept of hex fractions, so expecting a JavaScript programmer to understand the given example while omiting a vital algorithmic step makes the instruction set for the required deliverable incomplete. There is absolutely no need to explain how to do anything, just that it needs to be done.

"Hexadecimal fraction" itself is already more than enough to let you find out what that means.

I completely agree, and it would be great if the instructions even just mentioned the term "hexadecimal fraction" at literally any point.

So you're saying something is esoteric just because the language doesn't support it on the fly?

Not at all. It is esoteric because a majority of people cannot reasonably be expected to know about a functionality with such limited use case and reach.

You seem to be under the impression that my issue is with the program in some way. My issue is purely with the instructions provided for JavaScript. If you don't want to fix it, then you do you -- whatever. I was just hoping to save another JS programmer some time down the road.

I've been doing this for quite a long time and never stumbled across it. A quick survey of my entire develpment team, and not one of them were aware that hexadecimal fractions were a thing.

Yes, and there are more things in the world you, or I, don't know. So what's your point? Google is a thing, you know? I'm not supposed to be spoon-feeding something just because someone in the world doesn't know about it, as that's a lost cause.

"Hexadecimal fraction" itself is already more than enough to let you find out what that means. "Binary fraction" is used everywhere related to floating points too. It's not like didn't put anything.

The example is very unclear in regards to this specifically. For instance, there is zero disambiguation between literals and strings. As stated previously, it appears as if the 0. is simply prepended to the beginning of a hex string.

Again, your point? Writing hexadecimal fractions as 0.db9318c2259923d0 is the proper terminology, just like 0.1 binary decimals is 0.000110011001100.... I'm not responsible for people not reading the correct terminology and then proceed to complain about it being unclear.

my point was that if you are going to explicitly list out all of the other steps, then you should at least mention it as being one of the steps. It is not only an omited step

What omitted step? The description already says and convert them back to base 10. If you're asking to me detail how the conversion is done, nope, because it's basically asking for me to explain how MD5 is calculated.

it is also very esoteric considering that the language being tested doesn't even recognize hex fractions as being valid.

So you're saying something is esoteric just because the language doesn't support it on the fly? What kind of reasoning is that? Some languages don't have MD5 built-in either. So is MD5 "esoteric" now?

I don't understand what you mean by this?

Just because you failed to use parseInt to do the conversion directly doesn't mean it's my fault for that. The ball is at your court, so don't throw it at me.

In any case, I'm taking your issue as "you didn't mention what is hexadecimal fraction and how to convert it to decimal fraction", which I'm responding with "I've already provided more than enough information and I'm not responsible for you being dumb and takes a long time figuring out something from a description that already provides all the necessary information". If you're feeling salty, go calm down somewhere else; don't speak as if there are problems with the kata and it's my fault.

If you know what decimal fraction is, you should know what a hexadecimal fraction is.

That's a pretty bold statement. I've been doing this for quite a long time and never stumbled across it. A quick survey of my entire develpment team, and not one of them were aware that hexadecimal fractions were a thing.

And there's already an example given. There are more than enough information.

The example is very unclear in regards to this specifically. For instance, there is zero disambiguation between literals and strings. As stated previously, it appears as if the 0. is simply prepended to the beginning of a hex string.

Do I really have to outright explain every step how to derive a hexadecimal fraction?

I never said you should explain how to do it, but my point was that if you are going to explicitly list out all of the other steps, then you should at least mention it as being one of the steps. It is not only an omited step, it is also very esoteric considering that the language being tested doesn't even recognize hex fractions as being valid.

The fact that you can't just take a parseInt shortcut is not an issue either

I don't understand what you mean by this? parseInt('0.db9318c2259923d0', 16) and parseInt('0x0.db9318c2259923d0', 16) both return 0, and parseInt('db9318c2259923d0', 16) returns a completely incorrect (for this excercise) decimal value. JavaScript even throws a TypeError for (0xa0.a0).toString(10) but returns a proper decimal number for (0xa0).toString(10).

I've already answered about this below. If you know what decimal fraction is, you should know what a hexadecimal fraction is. I also did not invent the concept, as you already said there. And there's already an example given. There are more than enough information. Do I really have to outright explain every step how to derive a hexadecimal fraction?

The fact that your brain farted up for some time is not an issue to the kata itself. The fact that you can't just take a parseInt shortcut is not an issue either ;-)

All-in-all I thoroughly enjoyed this kata, so thank you for that. However, I have one major complaint. The algorithm instructions completely omit a very crucial step: converting the hex string to a fraction. As someone who had never even heard of the concept of a hexidecimal fraction, this took me a long minute to finally figure out. As neither "0.db9318c2259923d0" nor 0x0.db9318c2259923d0 are valid hex in JavaScript, it appears that the "0." is simply being prepended to the hex string, which is not at all the case. Had I not stumbled upon a StackOverflow discussion which mentioned hexidecimal fractions, I never would have been able to solve this, and been left forever wondering why parseInt was not returning the proper decimal representation.

Now all works, thanks.

Missed a whole block, I'll blame it on being the morning. Should be good to go.

Sure, sample tests are ok now, final tests (at least for me) still have assertSimilar and don't pass. Could you check it? I'll try later again and if it works, mark it as resolved.

Thanks Chrono, should work now? Would you like to test then mark this issue as resolved. Cheers.