Has to be a dupe

Non-decimal radices/Convert and Non-decimal radices/Output cover both built-in functions and user-defined functions. I don't see how this can't be a duplicate. --Mwn3d 17:29, 6 July 2011 (UTC)

Ok: Non-decimal radices/Convert - This tasks involve conversion. The binary digits task does not necessary involve conversion (unless this is required by the language)
The Non-decimal radices/Output requires native support for binary without conversion. The binary digits task does not require native binary support and conversion is allowed.
So this task is not a duplicate of either taskMarkhobley 17:40, 6 July 2011 (UTC)
Binary, Octal, Hexadecimal and Decimal are special cases, because they are sometimes handled natively from within the language, and sometimes they are not. A conversion task is not ideal for tasks that have native support, and a requirement for native support is not ideal for languages that do not have such a facility. These bases require their own sets of tasks. Markhobley 17:43, 6 July 2011 (UTC)
I don't understand the differences that you're talking about. "The results can be achieved using builtin radix functions within the language..." which is part of Non-decimal radices/Output, "or a user defined function can be utilized" which is part of Non-decimal radices/Convert. Neither is exactly the same, but the parts are in both, and I don't see what this task adds to them. I need a better explanation of the differences. What would be better is a demonstration of this task in a language that is also implemented in both the other tasks. --Mwn3d 17:48, 6 July 2011 (UTC)
"With conversion", "without conversion", them are all just words. What is a "conversion" exactly? Take an integer, give back a string, how is that not a conversion? Are decimal numbers stored inside the computer as digits 0-9, you think? --Ledrug 17:55, 6 July 2011 (UTC)
Right. I am talking about at language level, not CPU level here. Some languages allow a binary value to be used natively (from within the language). Other languages do not allow this (and therefore do not have binary support at a native language level). If the language does not have a radix specifier for binary (ie it does not have native support for binary), then we have to do some number crunching or string manipulation to derive the binary value as output. If a conversion routine does not need to be written within that language, because the language already supports this, we can say it handles binary "without conversion". If the language does not provide any native handling for binary, and we have to write some number crunching code, then this is a "conversion". Does that make sense? It will probably be clearer, when some of the conversion routines get pasted in.

Markhobley 18:15, 6 July 2011 (UTC)

Also a conversion routine that handle several different number bases, may not be the best way to handle a conversion to binary. The routines in Non-decimal radices/Convert are probably best used in generic circumstances when the target base is not known at compile time. If we know we are going to require binary, then dedicated binary handling methods are best deployed. Markhobley 18:23, 6 July 2011 (UTC)
So exactly what is the goal, take a string of binary digits and produce a native number type? Or the other way around? Your earlier explanation seems to go the opposite direction than the task description. Also hex and oct handling share a lot similarities with binary, only decimal is the odd one. --Ledrug 18:28, 6 July 2011 (UTC)
Return to "Binary digits" page.