how to solve this .....1100110.11 to base10?
help meee
Printable View
how to solve this .....1100110.11 to base10?
help meee
Learn how to do it yourself.
Decimal and Binary Conversion Tool
Can use this to help you too.
thank
Sure there are. The digits to the right of the period represent 1/2 + 1/4 = 0.375
Really... when's the last time you saw a CPU register with a fraction of a bit in it?
Think carefully now... We're talking about binary *representations* of fractions, not actual fractions. One of the big reasons why the original XT and 386 machines didn't have floating point math chips was the difficulty in representing .375 as a binary number. In fact it was all done in software back then, entire accounting packages were written to work on pennies for this exact reason.
No, but there are binary points, which serve the same purpose of separating the whole number portion from the fractional portion of a real number. The binary point is usually represented with a . just like the decimal point in base 10. And yes, that number could be in base 10. Presumably it's not though, since the OP asked that we help convert it to base 10.
Fractions of a bit don't exist, but bits representing fractional parts of numbers do. Hardware components that handle floating point numbers have been around since the XT and 386 days, in the form of a math coprocessor, like the 8087, 80387, et al. I would suspect it had more to do with fitting it all on a single chip die easily and cheaply enough rather than because "it's too difficult to implement". Nowadays, it's all on the CPU.
Actually it does.... Inside the computer it's all just On and Off... 1 and 0... There really is (for now) no other way to do this. The computer itself is a binary machine...
Yes we can use software to produce a base 58 numbering system if we like... but inside the machine it's all 1s and 0s... The CPU register (memory, storage, etc) does not know about the *translations* we apply to it's contents... it only executes the code needed to enact it.
When you see the number 14 on your screen, the computer will see it internally as a binary number... The characters on the screen are merely a software enacted translation of a binary number.
And, now, lets ask... how is that stored? ... well shucks, it's a binary whole number too.
In fact the early math processors used to have 7 bytes for an integer value and another byte saying where to put the decimal place when displaying it... Both of these numbers are whole numbers...
Also think about the problems of rounding and imprecision on floating point units... 8.0 ends up being 7.999999999 ... because someplace there's a 1 bit ambiguity in the calculations... Why is that ambiguity there? Well, because there are no fractions of a bit.
I don't think anybody is disagreeing here, much. It is true that when you represent something inside a computer, you will have to choose some representation of that number (whether it's two's complement (for ints), or IEEE floats (for floats), etc.). But that representation inside the computer doesn't have anything to do with the fact that the number "11011.011_(2)" exists. Of course "11011.011_(2)" exists, and has the value of 27 and three-eighths in decimal (or 27.375), or 033.3 in octal, or 0x1B.6 in hex, and "1000.10101..._(3)" in ternary. The numbers exist.
Why are you so stuck on this being tied to a computer? The OP just asked how to convert a binary number to decimal, nothing about the necessity for it to be stored in a computer (modern day or otherwise). Non-base10 number representations can exist in places other than a computer.
It's a sequence of bits that aren't necessarily "whole numbers". In IEEE 754, you have a sign bit (not really a whole number, more a "flag"), an exponent (admittedly, a signed integer) and a significand, which is only the fractional part of a scientific notation type number. It can be interpreted as a whole number if you want, but it's no more a whole number that .5, which has a 5 in it, which you could see as a "whole number" if you ignore the decimal point. There's no bit in there to store the . but it's as good as in there.
Actually, that ambiguity is there because you only have a limited number of bits to represent a number, not because "there's no fraction of a bit". You have the same problems with decimal numbers, or any base, if you restrict how many digits you can use. 1/3 doesn't have a finite representation in base 2 or base 10, but it does in base 3.Quote:
Also think about the problems of rounding and imprecision on floating point units... 8.0 ends up being 7.999999999 ... because someplace there's a 1 bit ambiguity in the calculations... Why is that ambiguity there? Well, because there are no fractions of a bit.
No, quzah. You're falling into the same trap as the others arguing about machine representation. The OP wanted to know how to deal with the written binary number that has a fractional part. And yes, you could shift the period left or right (like dividing by 2 or multiplying by 2).
The fact that C compilers complain when you attempt a shift (<< or >>) on a floating point data type does not alter the fact that yes, one could shift the 32 or 64 bit value, but since it's a mixture of biased exponent and significand without most significant bit... it would most likely break the number. Actually it would most closely resemble a squaring or square-rooting operation.
1100110.11 is 102.75
110011.011 is 51.375 see? Yay, shifting the "decimal" works.
(My mistake, 0.11 is 0.75... I said 0.375 earlier.)
Oh, and has anybody figured out what we're being warned against?
Heh heh, good one. For a minute I thought you wanted to know what the compiler warning is for attempting to shift a floating point.
For anyone wanting to argue, Wikipedia is always right and it shows examples of it:
Binary numeral system - Wikipedia, the free encyclopedia
No. You're falling into your own trap by saying binary is more than just 1s and 0s. It's not. Binary is just 1s and 0s. There is no "one or zero or decimal point". It's either one, or zero. That's all. There is nothing else.
Anything else is YOUR representation, which no different than you saying "you are interpreting how it's stored in memory!" There is no such thing in binary as a decimal place. It's YOU adding something more to binary. Binary is only ever 1 or 0. There's no place holder. That's you adding an extension to it.
Go read the entire first half of the Wikipedia article on it, and you'll see I'm right. There's nothing in binary that denotes a decimal point. That's an extension of binary. It's like saying your compiler supports extensions to let you use nested comments or something. That doesn't make it part of the core system, just because you extended it.
The concept of binary knows nothing of decimal places. It is simply 0s or 1s.
Quzah.
That's like saying numbers in base 10 are nothing more than a bunch of 0's, 1's, 2's, 3's, 4's, 5's, 6's, 7's, 8's, and 9's, with no place holder. But we obviously use our decimal number system to represent whole and fraction quantities all the time, by using an eleventh symbol, . which we also call the decimal point. It has no quantitative value in and of itself, but it does separate the whole quantity from the fractional quantity. A single digit on it's own (say 5), out of context can't represent one half of something, but you put it in the right place relative to the conventional . used for the whole-part separator, and 5 becomes .5, or one half (5 * 10^-1). Similarly, .1 in binary is 1 * 2^-1, or one half. Perhaps people are mixing up the concept of numbers vs. numerals.
Read it, still don't see how it proves you're right. As a matter of fact, the same article shows exactly how to represent non-whole numbers in base two. Same principle as in base 10 or any other base, just with powers of two instead of 10. Nobody is extending anything. What we're discussing is a number system not restricted by a computer's internal representation or some fanciful notion that a binary system can't have a whole-part separator because the symbol we would use for that is neither a 0 nor a 1.Quote:
Go read the entire first half of the Wikipedia article on it, and you'll see I'm right. There's nothing in binary that denotes a decimal point. That's an extension of binary. It's like saying your compiler supports extensions to let you use nested comments or something. That doesn't make it part of the core system, just because you extended it.
Binary by definition simply implies two-ness. In a binary, or base 2 number system, that means there are two possibilities for a digit, conventionally 0 or 1, but it could be anything. Sometimes we refer to it as high and low values or on and off. On a lower level, the computer doesn't see 0's and 1's, it sees voltage levels, like 5V or 3.3V for a value of "1". All that matters in binary is that there are two distinct values for a single digit. Just like base 10 has 10 distinct values for a digit.Quote:
The concept of binary knows nothing of decimal places. It is simply 0s or 1s.
If you want to get all pedantic about it, there are no "ones and zeros" in a computer either. A computer is made of atoms.
When's the last time you "saw" a number? The only place that numbers, decimal points, and fractions exist is... in your head.
In any left-to-right positional number-writing system, each digit represents x*b^N, where x is a digit within that system, b is the base of the system, and N is some integer which decreases from left to right. The decimal point means "the digit to my left has N == 0". The computer doesn't care about ANY of this.
Change the title of this post please. There is no urgency here. Also read the rules about creating such titles.
Prove it. Use strtol with a base 2 and have it handle your decimal point. Go on, show me how it's really not YOU just interpreting how you want to treat those 1s and 0s. Prove it.
There's a reason you can't treat floats as regular integer types of the same number of bits. You can't pretend you're treating it in the context of a program, and pretend you aren't at the same time. You can't try to be a purist on what binary actually means, and then try not to at the same time.
Quzah.
I see. That's odd, because I'm pretty sure I'm on a C programming forum. Anyway, if we pretend this is somehow a math forum instead, and we actually look at the OP:The thing is there's nothing here in the OP that says what the source format is, so it's perfectly fine for me to say that's not binary, and that it's already base 10. Furthermore, no one I've ever talked to on a programming forum has ever taken a string of 1s and 0s, and has stuck a decimal point in the middle of it. It's a mess of a conversation. But if you want to put decimal points in your binary numbers, go ahead.Quote:
how to solve this .....1100110.11 to base10?
help meee
Quzah.
That would be a perfectly wonderful response, if for no other reason that to get the OP to say what he really wants.
(EDIT: Okay this was originally a stupid comment. Stupid and pointless and stupid. I'm sorry.)Quote:
Furthermore, no one I've ever talked to on a programming forum has ever taken a string of 1s and 0s, and has stuck a decimal point in the middle of it.
Quzah.
I can't really see what any fuss is about.
If the OP asks for convert "1100110.11" to base 10 then seeing as how he has placed a decimal point there, he has clearly chosen to treat the bits to the right of it as fractional places.
The answer of how to convert it is to treat each digit position as a power of two, assuming it is binary originally, and then sum them all up.
For a number where the digits are ...ABCDEFG.HI..., the answer is:
... A*2^6 + B*2^5 + C*2^4 + D*2^3 + E*2^2 + F*2^1 + G*2^0 + H*2^-1 + I*2^-2 ...
(where ^ denotes the power function)
quzah, it is clear you have had no formal education in number systems. Perhaps all of your exposure to base 2 has been only within the context of what C library functions provide.
Number systems of any base can represent whole numbers and fractions. I can look for many examples where the "decimal point" is indeed included in definitions of systems other than base-10.
In this description for example:
Binary Number System
"Numbers can be placed to the left or right of the point, to indicate values greater than one or less than one. The number to the left of the decimal point is a whole number (10 for example). As we move further left, every number place gets 2 times bigger. The first digit on the right means halves (1/2). As we move further right, every number place gets 2 times smaller (half as big)."
But back to the Wiki article, it calls the period a "binary point". "Binary numbers can also be multiplied with bits after a binary point:..." and then gives an example of long-hand multiplication by doing 5.625 x 6.25 in binary.
I believe iMalc** and others who support decimal points and digits to the right side of that decimal point are quite right. That is the standard for base 10. Other bases are no different in that respect.
I believe Quzah is also correct, from a usage point of view. I've never heard of base 2 numbers which included a decimal point. Yes, it could happen, but experience says it's not likely to happen. We simply don't think of numbers less than one, in a base 2 format.
When I first saw that decimal point in the binary number, I thought it was a speck of dirt on my monitor. :p
I'd prefer not having these "evaluations" of what kind of education other forum members have, posted. It has the effect of directing the topic away from the subject, and into personal matters.
**Excellent post on this, iMalc.
I agree. I am moving this thread to General Discussions as what minimal context was provided makes it seem much more of a maths question than a C programming question.Quote:
Originally Posted by tabstop
hakimstm1b, if this is really supposed to be a C programming problem, then please start a new thread in the C programming problem with a better description of your problem along with your best attempt to solve it.
This is true. I have only ever used them to manipulate bits.The problem is that you cannot assume a number that only consists of 1s and 0s is binary (since all you are is seeing it as a string here).
What's this number?
101
Or this number:
10
If you said one hundred one, and ten, then you might have been right. Of course you just as easily could have been wrong too. Especially if my post had started with "What's this number?" and ended at "10".
Quzah.
O_O
Okay, despite the fact that I know this stuff, it must be said: a thank you to tabstop, iMalc, nonoob, and anduril462.
Soma
No disrespect intended. And I don't think quzah ever took it to be insulting. No 'formal' education simply means not having gone through a classroom setting in mathematical theory. Instead, having not encountered a "binary point" is simply a reflection of what is encountered in day-to-day practical C programming.
Quite right, the OP did not specify the incoming number base, although it is implied it is NOT base 10 as that was the desired target. Base 2 was assumed but probably safely so.
Not overly excited by seeing a floating point sign in a binary representation myself. I'd rather preferred if the OP teacher had explained to him the IEEE 754 binary representation and he was now asking us about such a datum.
For all purposes this bit representation with a floating point sign is entirely useless and will teach him nothing.
I tend to agree with NeonBlack.
Teaching that base 10 is a myopic way to look at the world will open up your mind to issues of scaling, precision, input/output conversions, logarithms, round off error, etc. If the student becomes comfortable with how a digit's position determines exponent, then they are ready to write programs that can do any base conversions, to and from base 10.
Understanding how a binary point works will make it simple to understand IEEE 754's exponent field.
I don't think starting with IEEE 754 format would make generalization of the math involved easier.
I don't see how this format will make it easier. It offers no shortcut that I can see. No new information that isn't already available through traditional base 10 representation. It's not because I put a floating point in a binary representation that suddenly one has an eureka moment. What's worse, the conversion technique is a gimmick that simply inverts the technique used for the integral part. It does not provide any new knowledge and the whole thing will have to be relearned when it comes the time one really has to understand floating point binary representation in a computer.
I entirely fail to see the value of this. It cannot be applied in any way. So it fails as a generalization. A generalization would save important knowledge when it came the time to get into the specifics. But this representation saves instead the wrong knowledge. In other words, what he learned here cannot be applied to what he will have to learn later.
Binary representation of floating point numbers differs greatly from binary representation of integer numbers. It has in fact... surprise... a lot more in common with decimal representation of floating point numbers. If you want a good generalization, there you have it. It's a lot easier to make a student understand floating-point representation in binary format by showing them this simple decimal representation, and starting from there:
314.1592 X 10^-2
Pretty much everything they need to know is represented here.
While that might be what you're comfortable with, it's simply not how this forum, or most forums for that matter, have historically worked. Topics are answered with in the context of the forum. If someone were to post a question about history or literature in the C programming forum, then perhaps you might not feel comfortable answering it because you identify that it is not related to programming. This is no different... the fact is that you and many others here simply seem to feel that math is "close enough" to programming to answer in a programming forum, which is not correct. It's not a programming question, and in my opinion, the most valid answer would be to instruct to the OP that his/her question structure does not agree with the subject matter of this forum and that the question should be either rephrased to fit the subject matter or directed to another location. Something I feel confident Quzah would have said had he responded to this thread before anyone else.
While there is no obligation, there certainly is an expectation to respect the environment of the forum and to both ask and answer questions with full regards to that environment. This is to ensure that the subjects presented don't confuse people who are not as familiar with the subject or subjects presented as you or Quzah certainly are. Try and tell me that if this thread went on answering the question with respects to number systems rather than programming that some first level CS student wouldn't think that perhaps a significant amount of modern computers might store floating point data in that format.
By the way... I find it tremendously insulting for people to suggest that Quzah or anyone that has been on this forum as long a him could read 1100110.11 and wouldn't comprehend what is being implied by the OP. You don't need "formal education in number systems" to know what is being said there... but the very fact that you're talking about number systems in a C forum is exactly what I, and Quzah, and a few others have an issue with.
And how is our student going to get through learning about IEEE754 without dealing with a floating point sign in a binary representation? That's what the mantissa of a IEEE754 float is, after all. (EDIT: What am I saying? The mantissa is fixed point. Still has a (binary/radix) point, though.)
Since we're off in the weeds, here's how you convert 1100110.11 to base 10.
Shift left by 2, which is equivalent to multiplying by 4:
1100110.11 -> 110011011
Convert the (now point-less) value to decimal:
110011011b -> 411
Divide by the factor of 4 that was introduced above:
411/4 -> 102.75
Problem solved. You'd think people had never manipulated fixed-point numbers before.
No. It has an exponent. And the mantissa is an integral.
The conversion to decimal does not require you to represent a radix in binary format. You may for illustrative purposes (for readers of Wikipedia). But that doesn't make it a standard practice... and I will go as far as saying, a desirable one.
What would you do that for? You got to all that trouble of converting your IEEE-754 number into a radix-based binary notation and you didn't even start converting to decimal. That's two steps when you could have just taken one: convert mantissa and exponent to decimal, attach sign, and you have your decimal representation in scientific notation. What can possibly be confusing about this is beyond me (and I'm not a even a math person).
I suppose at the end of the day, whichever method you choose you'll end up getting there. That I agree. But I personally fail to see the advantages of a floating point symbol in a binary representation. I think is counter-intuitive, and definitely not a generalization of the vastly different method by which these values are actually stored.
For anyone who wants to represent real numbers in binary, the decimal is as advantageous as it is to anyone wanting to represent real numbers in decimal.
I fail to see why the fact that it's impossible for computers to represent some form of information in a certain way implies that representation in that certain way is useless, invalid, or incorrect. Computers use binary, binary doesn't use computers. Furthermore, binary defines binary. Computers may use only a subset of binary(the integers), but that doesn't redefine binary as only capable of representing integers.
A bit is supposed to be the smallest piece of information available. This is not just computers.
And here I was doing an effort to demonstrate why it isn't useful as a teaching mechanism...
>> I fail to see why the fact that it's impossible for computers to represent some form of information in a certain way implies that representation in that certain way is useless, invalid, or incorrect.
For that I would require to provide you with an analogy. And then we would start debating the analogy instead of the actual issue. I pass...
I think my words on the matter speak for themselves. I'd rather have you use them for your argument (contradict them by all means), instead of denying them without making an effort to disprove them. In other words, I get it you think this is a valid and useful representation. But you failed to explain why.
>> that doesn't redefine binary as only capable of representing integers.
Isn't that something everyone agrees?
A liter is a fundamental unit of volume, but that doesn't mean you can't have 0.1 liters of something. Same goes for bits.
What might not be immediately obvious is that the bit as a unit of information is actually an arbitrary unit, just like the liter. We measure information in bits because we, humans, have designed computers to work on the basis of on-off (binary) states.
Ultimately, a bit of information is the amount of information needed to describe which of two possible values of a random variable actually occur, if the variable is uniformly distributed. A good example is a coin toss. Assuming both sides are equally likely, it takes 1 bit to represent the outcome of a single toss.
But if the two sides are NOT equally likely, it turns out you can take advantage of this to represent the outcome using less than one bit of information. I'll omit the exact formula, but as an example, if you had a coin that came up heads 25% of the time and tails 75% of the time, you could actually encode the state of the coin using only 0.881 bits.
Of course, you can't actually WRITE DOWN 0.881 bits, you need to use a whole number of digits, but that is purely a property of the positional writing system we use to represent numbers (regardless of what base is used), it doesn't actually mean that a fractional number of bits of information can't exist.
If you want to get a little crazier, you can measure information in units called 'nats', which is sort of like using base e for everything -- in this case, the base of the number system isn't even a rational number, much less an integer.
I had to read that a couple of times before I realized you meant integer. The mantissa of IEEE-754 numbers is not an integer. It is the fractional part of a number with an implied "1." prefix. In other words, it is a fixed point real number.Quote:
No. It has an exponent. And the mantissa is an integral.
I know what you are saying, but you are grossly oversimplifying what you are claiming. If nothing else, you'd have to remember the bias and scientific notation calls for a decimal base.Quote:
That's two steps when you could have just taken one: convert mantissa and exponent to decimal, attach sign, and you have your decimal representation in scientific notation.
[Edit]
Come to think of it, that doesn't account for subnormal numbers either, but I will not go there if you don't. I hate dealing with them.
[/Edit]
I find it useful as a teaching tool. Using that representation along with an explanation of dyadic rationals make explaining why mechanisms like IEEE-754 can't accurately represent categories of simple decimal fractions.Quote:
And here I was doing an effort to demonstrate why it isn't useful as a teaching mechanism...
For a lot of examples, grab a copy of "Data Compression: The Complete Reference".Quote:
I'll omit the exact formula, but as an example, if you had a coin that came up heads 25% of the time and tails 75% of the time, you could actually encode the state of the coin using only 0.881 bits.
Information theory is fun.
Soma
He said "A bit is supposed to be the smallest piece of information available." not "A bit is supposed to be the smallest number available.". There is a significant difference.
EDIT: My point is => In computers we have pieces of information while in our heads we have numbers. Mixing those two produces these meaningless arguments like it this thread.
In other words, you've repeated what brewbuck just said. At least we have a consensus now.Quote:
My point is => In computers we have pieces of information while in our heads we have numbers. Mixing those two produces these meaningless arguments like it this thread.
No, because brewbuck is wrong. You can't compare a bit to a liter, because a liter is not the "smallest" of anything. There's something smaller than a liter, so you can't compare a liter to a bit and say they're similar. The best you're getting for a comparison to a liter is a byte.
"A liter is like a byte, because there's something smaller in each unit of measurement!"
That's not even close really, because it would be more like comparing a liter to a megabyte. Or a gigabyte. There is not a "smallest unit of liquid measure in existence" that you can substitute for "liter" in the comparison.
Say we make one up. The smallest unit of liquid measure is a "drop". A drop then would be like a bit. You cannot go sub-atomic on me and say there's a quark that's smaller than a drop of water, because for our comparison to be valid, we have to have something that is indivisible. THAT unit is the same thing as a bit. THAT unit, that I'm calling a drop, would make a his comparison valid.
You aren't comparing the "smallest possible expression of measurement" to a bit (which IS the smallest expression of measurement in its respective field), so your comparison is invalid. Bits can't have decimal points, because if you tried to divide bits smaller, then that new result would automatically be considered a bit. Why? Because a bit is the single smallest expressible form.
I honestly have no idea what you guys are trying to argue now, but you're wrong when you compare a liter to a bit.
Quzah.
The point brewbuck was making had merit, because he conceived a reason why one would like to add a decimal point to a binary notation. Inn his example, for the convenience of representing a fractional number of bits. He indeed demonstrated one such need when he discussed percentages and odds.
Of course, I disagree with that simply because we are not discussing the applicability of the binary representation on non computational areas. We are discussing the binary representation on what it concerns computers. And lo and behold, we are already have a binary representation for floating and fixed point values.
Why do we need to resort to another one when teaching the binary system -- and what advantage it can possibly have -- is what no one seemed to explain yet.
O_oQuote:
Bits can't have decimal points, because if you tried to divide bits smaller, then that new result would automatically be considered a bit. Why? Because a bit is the single smallest expressible form.
Okay. I have a specific quantity of entropy here in my pocket. It has an expression of `N' over `M' bits for every `O' bits. I have only enough of this quantity to affect a single byte of information. I have only 3 bits of entropy. Do you seriously want me to start expressing this fractional quantity as it relates to the information in bits without a fractional portion? If so, what do we start calling real bits? You know, the ones that can fully represent a single '0' or '1' state? What do we call those now that we call this smaller measure bit?
My vote is for spoont. I like spoont. We'll have the bit, the byte (still 8 bits), so forth and so on, and the spoont which can represent an unknown but specific quantity of bits and also a single '0' or '1' state.
Awesome. I can't want for teraspoont drives.
Soma
The problem is that the defintion of a bit states that it is indivisible. Stop thinking of it as a number, it's not. But as for number representation ... take an unsigned int, now tell me how you get below zero.
Here's a real world example: absolute zero. Go below that. Oh, wait, you can't. Because by definition, it's the absolutely lowest possible representation of temperature.
Why are you still confused?
Quzah.
You can find it insulting on behalf of quzah if you like.
According to quzah: "The thing is there's nothing here in the OP that says what the source format is, so it's perfectly fine for me to say that's not binary, and that it's already base 10."
So quzah himself states that he has no trouble interpreting the OP's question as being in base 10 to begin with. This, presumably, to try to save face in a losing argument. [flame war alert!]
I really don't see a problem if someone has not had exposure to a binary point representation of numbers. His assertion that it doesn't exist is simply wrong on that basis.
Binary point is not something supported by library functions scanf, or atoi if they include native base 2 at all. Base 10, 16, 8 only (%d, %x, %o). And then only for integers. There is no binary support except the suffix 'b' for constants I believe. Maybe some compilers only.
Of course...10 is the only *real* number base (in fact, all bases require as many digits, don't they?). :cool: The base-10 point is almost superfluous...
I wasn't trying to save face, because I don't care if I'm wrong here. I'm fine that people use decimals in binary. I don't, but you can if you want to. It doesn't affect me.
I was just being pedantic. You cannot look at any arbitrary number and know what base it is. You just can't. You can't know if I mean "10" as ten or as binary, or as something else entirely in hex. We all assume that "10" is ten, because that's the base we normally use. But without them telling use what base it is, you cannot do anything more than guess. I don't care if I win whatever we're arguing about now. I'm just being pedantic - you cannot know what base he actually meant, because he didn't say what he actually meant.
Quzah.
Every base can be expressed everyway we like it to. Take hexadecimal for example:
The typical and widespread representation is: 0123456789ABCDEF
What if we used dots for every digit: 4D42 <==> 4.13.4.2
There's no actual limit. The limit is in our minds and our way of thinking, model, or beliefs
I'm surprised this entire argument has even happened.
First of all, despite the fact that "10" could represent a number in essentially any base, I think it's quite easy to derive from the context of the OP's post that he was clearly wanting convert a base 2 number to a base 10 number. We're all about context here, people. Be sensible, and use it.
Second, it's also clear that any number base can represent fractions, whether it be base 2 (binary), base 3, base 10, base 11, base 26, or base 2024236. Just because we don't normally write fractions using base 2 the same way as we do base 10 doesn't mean it is an incorrect way to do it.
I understand and totally agree with that, just like ASCII, just like any programming language! For example, it's difficult porting from Microsoft compilers to those of GNU because they have different syntax in some areas. Communication has broken down between those compilers, although there're tricks to get past them, the established and universal preprocessor! etc, etc, etc...
:)
You cannot argue this in the context of this thread, and allow for decimals in binary numbers. This thread appeared on the C board, which sets the context and the "established conventions". You never have a decimal place when you manipulate binary numbers in C - because it would be stupid and backwards to do so. The input would have been a string, and you would be converting from a string to a given base - in this case, base 10.
Since there are never decimal points when working with binary (bit manipulation, because you can't manipulate the bits of a floating point number directly) this number automatically defaults to being a string of base-10 numbers, in the provided context.
You cannot argue for following conventions, and have that be anything other than a base 10 number, in the context it was provided. Either your argument is wrong, or the context provided was wrong. You can't have both be right in this thread. (Yes, I'm just arguing for the sake of arguing now.)
You can't say "you only get one decimal point" (which is what you're saying), and at the same time say "yes there must be one decimal point for binary numbers", in the context it was provided (being on the C board), because nothing you ever do with binary numbers in C uses a decimal point.
Quzah.
Well, here I disagree, quzah. Been pretty much in agreement with you so far, but here I think you are being too intransigent. So far I've looked at this thread as some schoolboy assignment whose teacher asked him to convert a binary notation that uses a decimal point. And I completely agree this is not the correct way of teaching the handling of real numbers by modern computers. In fact, it's completely obtuse and will serve no purpose as a teaching tool.
However the notation itself exists. And can be instrumental on certain very specific cases where C is being used. And even in a direct relationship to how these numbers are stored. This is the case of systems where there's no FPU. Here, you bet it will be common practice for numbers to be represented in the Qm.f notation. They aren't stored exactly this way, but are used in this way by C. Naturally the decimal point doesn't exist. But its representation is fundamental in any specs literature about these systems, or in code comments.
Now, you and I both know this isn't the case. My last post on this thread was basically in jest. I simply know for a fact the OP wasn't being taught about systems without an FPU because if he were, the enunciate of the problem would be telling him the actual notation used. And he would be telling us that too in his question. The only possible real answer to the initial question is "What's the notation used?". We can't convert this number from Qm.f, because the actual notation could be fxm.b (*), or something else entirely. Some here assumed something akin to a decimal representation. But we simply don't know what's the notation of that representation.
Because he didn't tell us anything of that, we know for a fact this isn't about systems without an FPU. So it's safe to say that's a wrong representation for decimal numbers and it should be banished. But make no mistake you need that notation, and you'll use it when talking about (not coding) systems without an FPU.
...
(*) before anyone complains... yes, you can have 9-bit boundaries.
Quazah,
I'm only emphasising what Sipher said, that the relation between a sign and what is signified, is arbitrary. Then I go on to say that eventhough it's arbitrary, it's not up to individuals to make up their own, but to use established conventions. That's it. I haven't ever seen a decimal point in a binary number myself, and I'm not arguing for it's use.
Well since we've never heard from the OP again, and since it's been moved, and since everyone's tired of pointless debate... I'm off to make a sammich!
Quzah.
It really doesn't make a lick of difference how C handles bit manipulation. The OP obviously was simply asking how to write a base2 to base10 converter. It could have just as easily been how to convert fahrenheit to celcius. Would you argue that it's impossible and doesn't make sense because C doesn't know how to handle temperatures? No, the temperature, just like the base2 number the OP is trying to convert, is just an abstract entity contained in a string and you can treat it however you want, regardless of C's internal limitations.
From what i've read here, the real problem is that not everyone have the same opinion about what a number is! Since we can't force someone to believe what we do, lets end it here, please. ( Quoting quzah :D )
III.MCDXV
or even,
X.XXMCDXV
My gift for all you notation liberals in here. And please, don't pay attention to anyone who tries to tell you there should be some means of formal communication between programmers. We all know that is nonsense. Communication is overrated.
According to you and quzah since you didn't specifically declare what interpretation to apply and C wouldn't handle those apparently values natively they are meaningless and shouldn't be discussed on a C programming forum and any guess of a given interpretation should be met with contempt.Quote:
My gift for all you notation liberals in here.
Soma
Why on earth would it be important? It's obvious that if you want accuracy in C, you don't use floating point numbers. You don't need to know anything about floating point numbers beyond that. You aren't ever going to use them for anything critical, so who cares what can be represented?
Quzah.
The difference here is that the above wasn't posted on the C board, asking how to convert it to base 10. Also, it isn't "obvious" by looking at it that it could fall into multiple base types. As much as itsme86 wants it to be clear, it is only guessing as what base the first one is in, because you have a 20% chance per digit, in any base 10 number you write to end up with something that "is obviously binary!"
0
1
10
11
100
101
110
Which one of those numbers was binary again?
Quzah.