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)

For example: J has a special binary type, which is much like a boolean type in other languages, except that its values are 0 and 1 instead of true and false. It's explicitly a numeric type. And a binary number can be represented as a list whose members are this binary type. Thus, the native representation of this type contains spaces (since that's how J represents numeric lists). J also has a primitive to change a number into a binary lists and another primitive for the inverse operation. So... in this context -- where the language has a type that corresponds to "binary digits" and another type that corresponds to "normal numbers" it can make sense to talk about conversion, no? But I think the question is: what does this distinction mean when you do not have this kind of infrastructure? --Rdm 18:59, 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)
Given a decimal value n, produce its binary digits. Some languages will need to perform number crunching and string manipulation to achieve this. Markhobley 18:36, 6 July 2011 (UTC)
Ok I assume when you say "decimal", you really mean "integer". Now I'm curious, there is a language that doesn't need any computation or string manipulation to produce a string of binary digits? --Ledrug 18:41, 6 July 2011 (UTC)
Yes. Some languages can output binary numbers natively.Markhobley 19:22, 6 July 2011 (UTC)
Fundamentally, all languages that run on binary computers output binary numbers natively. It's a matter of what they output those numbers to, and what constraints the language places on where it gets those binary numbers from. ASCII is an example of direct binary output. But that might not be what you meant? --Rdm 19:39, 6 July 2011 (UTC)
Return to "Binary digits" page.