Maths

[reaper]

Here is an online calculator, so put in the floating point variables value and get the decimal number.  It explains what each bit means and how to calculate the value.

http://www.h-schmidt.net/FloatApplet/IEEE754.html

Thing is, this is for modern cpu's, and they work with 32 bit floating point values.  I'm not sure the question really means to find the floating point value, although you could calculate it from the wikipedia article, as it references an old 16bit floating point format.

If it's just to base 10, put in the 0's and 1's under binary in windows calculator, then click decimal.  Sounds to easy, it's probably the former.

 

[QwazyWabbit]

It's impossible to determine what your 16 bits means in a "floating point" context without knowing what floating point format is being used. The IEEE 754 specification is fairly straightforward but might not apply in your case. You need to specify what method is used to encode the number.

As for the expression of exponents, we write 1.78x10^-7 when we want to express it in scientific notation. One point seven eight times ten to the minus seventh power. This is usually NOT how it's written or printed as a "float" on computers. When inputting or outputting floating points it's written as 1.78e-7. In this case the "e" replaces the "x10^" part, as in "times ten to the power". (it's easier to type and translate "e" than it is to type the somewhat ambiguous "x10^") On calculators this key is labled "Exp" for exponentiation.

As for the mantissa and exponent parts, the exponent is the positive power of two part of the number, each bit represents some 2^n. 2^0 = 1, 2^1 = 2, 2^2 = 4, etc.

The mantissa represents the fractional part or the negative powers of 2 as in 2^-n. Setting the first bit is 2^-1 and this is simply translated as 1/2^n, for example 2^-1 = 1/2^1 or 1/2; 2^-2 = 1/2^2 or 1/4 and so on.

The number of bits you need to encode for computer purposes depends on the range of floating point numbers you need to compute. The IEEE specifications were intended to standarize the formats for a wide range of numbers and to allow software and silicon to be properly designed for the accepted standard.

There is a problem with representing floating point base 10 numbers with a binary (power of twos) representation. Can you see what it is?

Here is a Windows console program in C that interprets your 16 binary digits in different ways:

//
// maths.cpp
//

#include "stdafx.h"
#include "stdio.h"
#include "conio.h"

int main(int argc, char* argv[])
{
   union maths   // Declare union
   {
      int    i;
      long   l;
      float  f;
      double d;
   } num;
   
   num.d = 0;   // zero the 64 bits of the union

   num.i = 0x52c6;      //0101001011000110
   
   printf("%x as hex\n",num.i);
   printf("%i as int\n",num.i);
   printf("%d as long\n",num.l);
   printf("%e as float\n",num.f);
   printf("%g as double\n",num.d);
   printf("A integer is %i bytes\n", sizeof(int));
   printf("A long integer is %i bytes\n", sizeof(long));
   printf("A float is %i bytes\n", sizeof(float));
   printf("A double is %i bytes\n", sizeof(double));
   getch();
   return 0;
}

The output is:
52c6 as hex
21190 as int
21190 as long
2.969351e-041 as float
1.04693e-319 as double
A integer is 4 bytes
A long integer is 4 bytes
A float is 4 bytes
A double is 8 bytes

[[BTF]adam]

Wooow, that looks like code oO I'll write out what the actual question is for clarification, I just want to add that I appreciate this help a lot and im not just throwing out questions I have for assignments expecting them to be done for me, i'm proper trying to understand how the answer was acheived so I can do them myself in future etc.

Anyways the question goes like this?

"á flóating poínt number ís stóred úsing two bytés (16 bits), starting from the left the first 12 bits are used for the mantissa and the remaining four bits are used for the exponent, both the mantissa and the exponent are stored in twos complement form when negative.

(a) Determine the base 10 number represented by 0101001011000110

^^^^^^

the accented letters were because a couple of our lecturers seem to be very nazi about us using the internet for assistance, and they just paste in question names into google on these assignments and try to find people plaigerising (or however it's spelt, I prefer the term copying ). of course this is not what im trying to do but it could seem that way w/o clarification.

[QwazyWabbit]

Ah! Now we have something to deal with.

Exponent = 4 bits, signed.
Mantissa = 12 bits, signed.

data = 0101001011000110

or
010100101100 0110 as mantissa and exponent split, starting from the left.

Now nothing copy-pasted mindlessly off the net can help us because all the usual tools are useless because this is a unique fp format. We have to crank it out by hand.

Twos complement form means the leading zero is the sign bit, 0 when positive, 1 when negative.
Both mantissa and exponent are positive, the left-most bits are 0.

Exponent is interpreted left to right as 2^0 + 2^1 = 3

Mantissa is interpreted left to right, MSB ( the least negative power of 2) on the left after the sign bit:
2^-1 + 2^-3 + 2^-6 + 2^-8 + 2^-9  = 1/2 + 1/8 + 1/64 + 1/256 + 1/512 = 0.646484375

3 * 0.646484375 = 1.939453125

Unless I am interpreting the exponent and matissa backwards because their format specification is incomplete.

[reaper]

"
Floating-point and endianness
On some machines, while integers were represented in little-endian form, floating point numbers were represented in big-endian form. [3] Because there are many floating point formats, and a lack of a standard "network" representation, no standard for transferring floating point values has been made. This means that floating point data written on one machine may not be readable on another, and this is the case even if both use IEEE 754 floating point arithmetic since the endianness of the memory representation is not part of the IEEE specification. [
"

It's a special floating point format, but you should go by x86 standards, since x86 is the pervasive standard hardware, anything else would be specified.  On x86 processors the data is in little endian format - on x86, integers and floating points use the same endianess.   

[QwazyWabbit]

It's a special floating point format, but you should go by x86 standards, since x86 is the pervasive standard hardware, anything else would be specified.    

It's a special format because it's for a course he is taking. They make it special to prevent simple copy-paste operations off internet resources or using gizmos off the web like your IEEE floating point tool. The whole point is to teach them the techniques and principles of numeric representations.

On x86 processors the data is in little endian format - on x86, integers and floating points use the same endianess.

No, they don't.

Go play with that floating point web tool you cited. Then go read the IEEE 754 format. Then go play with a debugger and write some floats and look at the memory bytes comparing floats and ints.

1.0 float is 00 00 80 3F in memory not the 01 00 00 00 you would see when storing integer 1 on x86. Even more fun, 1.0 double is 00 00 00 00 00 00 F0 3F, not even the same number as float. The fact your compiler can cast them to the same number does not mean they are stored the same.

[reaper]

1.0 float is 00 00 80 3F in memory not the 01 00 00 00 you would see when storing integer 1 on x86. Even more fun, 1.0 double is 00 00 00 00 00 00 F0 3F, not even the same number as float. The fact your compiler can cast them to the same number does not mean they are stored the same.

That is not the case.  Take a look at the output showing the contents of the memory address storing the variable.  Take a look at the integer in memory, it is the reverse order on x86, which is the pervasive platform. 

hello.c x changed to integer

(gdb) print &x
$3 = (int *) 0xbfd03d20
(gdb) x 0xbfd03d20
0xbfd03d20:     00000000000000000000000000000001
(gdb)

hello.c

#include<stdio.h>

main()
{
float x=1;
float y=2;
printf("%f",x);
y=x+1;
}



someserver@neverlandranch.com:/var/scripts# gcc -g hello.c

someserver@neverlandranch.com:/var/scripts# gdb a.out

GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...


(gdb) break 6
Breakpoint 1 at 0x80483dd: file hello.c, line 6.


(gdb) run
Starting program: /var/scripts/a.out

Breakpoint 1, main () at hello.c:6
6       float y=2;
(gdb) print x
$1 = 1
(gdb) print /t x
$2 = 1
(gdb) print &x
$3 = (float *) 0xbfea8ed0
(gdb) x 0xbfea8ed0
0xbfea8ed0:     00111111100000000000000000000000
(gdb) quit

Where the left most bits are high order on x86.  The endianness is the same..

edit: the endianess and binary representation of 1.0 vs 1 is the same, the endiness doesn't change on the same x86 system. and I named the variable "x", but in "x 0xMemAddress" x is a gdb command.  If you are calculating the base10 number from the binary representation, you can see the high order bits on the left, this is the endianness.  Which I was saying could be known before since almost everything is x86.  Everything else was spelled out in the format of the binary representation of the floating point value.

[QwazyWabbit]

gdb is using carnal knowledge of the data to present it to you in those formats.

I repeat, look at the memory dump.

And do this while you are at it:

#include <stdio.h>

int main(int argc, char* argv[])
{
   int i = 16384;
   float f = 16384.0;

   printf("%x as hex\n",i);
   printf("%x as hex\n",f);
   return 0;
}

[reaper]

gdb was changing the endianness of the bytes.  when you change the formatting it goes on to the next command. the actual values in memory below for, first, integer 256, second float 1:

$4 = (int *) 0xbfdc0de0
(gdb) x /4tb 0xbfdc0de0
0xbfdc0de0:     00000000        00000001        00000000        00000000
(gdb)


$4 = (float *) 0xbffe7800
(gdb) x /4tb 0xbffe7800
0xbffe7800:     00000000        00000000        10000000        00111111
(gdb)

If you assume the question is for x86, which seems reasonable, you have to read the bytes from right to left.  I imagine the bit ordering is the same, as it is for the integer variable above.

So it appears you have to read the bytes listed above from right to left, and calculate the floating point value.  You read the bytes from right to left, and go by IEEE 754 half precision format to calculate the decimal floating point number. Looks like it can be calculated right from:
http://en.wikipedia.org/wiki/Half_precision  Although I wonder if the byte ordering was already changed for the binary number you're presented.  And if the endienness is the same for 16bit floating point on x86.


But I am tired.

fun fun

 

[QwazyWabbit]

Thank you.

Endianness in storage is irrelevant when choosing a numerical representation like floating point. The bit pattern of IEEE754 is presented for convenience of the specification and is platform independent. It is up to the implementation of the platform to properly store, retrieve and compute values with it.

Endianness and x86 is irrelevant and cannot be assumed. That's not what the assignment was about. The assignment was about a unique representation and it was intended to teach the principles of representation methods. The representation was deliberately chosen to not conform with any known standard in order to prevent Internet copy-cat or plagiarism. It was chosen so the standard tools were useless and the work had to be done by hand and mind. The task was to read the specification and perform the implementation and obtain correct results within the specification. When implementing a specification one cannot assume anything outside the specification, including the processor it may or may not be used on. For all we know, it might be a custom ASIC or a DSP.

There are also glaring holes in the specification, especially with respect to the endianness of the bit-wise representation since "twos complement" and "left to right" are in conflict as I interpret them. A twos complement representation implies the bit values increase from right to left, but the specification demands the reading of mantissa and exponent be from left to right, therefore it is implied that the bit values increase from left to right for this case and this is probably why adam was having trouble. The specification is incomplete and allows for mis-interpretation, IMO.

For example, the binary exponent 0110 has the value 3 when read from left to right with the sign bit on the left. It has the value 6 when read from right to left with the sign bit on the left. Which is it? If one assumes the left to right interpretation applies to the bit pattern as well as the partition of the mantissa and exponent then my implementation is correct and it has the value 3. If the left to right partition only applies to the mantissa and exponent parts and not to the bits within each of them then the right to left values apply and my implementation is wrong. The specification as given, is not clear on this.