From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jonas Amoson" To: <9fans@9fans.net> Date: Wed, 20 May 2009 03:46:57 -0700 Message-ID: <0A6636567CF044608F1AEB6AEEAA4AEB@mail2world.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2E793_01C9D8FD.9FA53660" Subject: [9fans] plan 9 floating point representation Topicbox-Message-UUID: fb31af78-ead4-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. ------=_NextPart_000_2E793_01C9D8FD.9FA53660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Hugo, Done some experiments with the indivudual bits in Lunix, and would be very surprised if it is not handled the same under Plan 9, given the same hardware architecture. The exponent is stored in base 2, but What might be a bit confusing, is that it is not stored using two's complement, but rather using a bias. If you have an exponent of 8 bits (in a 32-bit IEEE float) an exponent of zero is represented by '10000000' or 127. Simply add the desired exponent, whether pos or neg. -1 will be 126, +1 will be 128. This link explains the whole thing in more detail: http://steve.hollasch.net/cgindex/coding/ieeefloat.html /jonas <-----Ursprungligt Meddelande-----> From: hugo rivera [uair00@gmail.com] Sent: 20/5/2009 11:50:51 AM To: 9fans@9fans.net Subject: [9fans] plan 9 floating point representation Hi, I am learning a bit about floating point representation and I am wondering about how plan 9 does this. According to IEEE 754 (I think) the convention used by C for single precision floating point numbers is to use 24 of the 32 bits available for the significand and 8 bits for the exponent. It seems to me that plan 9 follows this convention but I am still kind of puzzled about the base of the exponent. I've been experimenting (on a 386) a while and it looks like a base 4 to me, which is kind of strange, since I was expecting a base 2 or 10. I think I got something wrong, but I would appreciate if someone can explain this to me to have a better idea of how this works. It looks to me that this stuff is very machine dependent (or language?), is it? The point of all this is to classify raw data (4 byte length) according to their magnitude, I don't really care about the significant. This is just an exercise for me, since there are other easier ways to do it. Saludos -- Hugo .

_______________________________________________________________
Eniro Supers�k - �r vad det heter ------=_NextPart_000_2E793_01C9D8FD.9FA53660 Content-Type: text/html Content-Transfer-Encoding: 7bit Hello Hugo,


Done some experiments with the indivudual
bits in Lunix, and would be very surprised
if it is not handled the same under Plan 9,
given the same hardware architecture.

The exponent is stored in base 2, but What
might be a bit confusing, is that it is not
stored using two's complement, but rather
using a bias. If you have an exponent of 8
bits (in a 32-bit IEEE float) an exponent of
zero is represented by '10000000' or 127.
Simply add the desired exponent, whether pos
or neg. -1 will be 126, +1 will be 128.

This link explains the whole thing in more detail:
http://steve.hollasch.net/cgindex/coding/ieeefloat.html

/jonas

<-----Ursprungligt Meddelande----->
  From: hugo rivera [uair00@gmail.com]
Sent: 20/5/2009 11:50:51 AM
To: 9fans@9fans.net
Subject: [9fans] plan 9 floating point representation 

Hi,
I am learning a bit about floating point representation and I am
wondering about how plan 9 does this.
According to IEEE 754 (I think) the convention used by C for single
precision floating point numbers is to use 24 of the 32 bits available
for the significand and 8 bits for the exponent. It seems to me that
plan 9 follows this convention but I am still kind of puzzled about
the base of the exponent. I've been experimenting (on a 386) a while
and it looks like a base 4 to me, which is kind of strange, since I
was expecting a base 2 or 10. I think I got something wrong, but I
would appreciate if someone can explain this to me to have a better
idea of how this works. It looks to me that this stuff is very machine
dependent (or language?), is it?
The point of all this is to classify raw data (4 byte length)
according to their magnitude, I don't really care about the
significant. This is just an exercise for me, since there are other
easier ways to do it.

Saludos
--
Hugo

.

_______________________________________________________________
Eniro Supers�k - �r vad det heter ------=_NextPart_000_2E793_01C9D8FD.9FA53660--