In reply to a post by RobertoS:

had a hardware register which enabled calculations in £sd or imperial weights to be carried out easily.

Well it would do that, wouldn't it, in a computer designed for Joe Lyons' teashops and grocery emporiums! LOL

Exactly.
ICT 1900s with Cobol were like going back to the dark ages when I moved onto them.

Well, that's Cobol for you! Thankfully I never used it on 1900s

Someone had better tell Microsoft to stop using KB and MB the way they do then.

Look in explorer and see how many bytes they have to a kilobyte - you'll find it is 1024. I don't have an apple to check but suspect it is the same.

It has been the case for at least the 20 years I've been working in IT. File sizes are always done in factors of 1024. Memory always has been (as mentioned above). When hard disks came out they were usually done in factors of 1024. Then some bright spark decided that their hard disks would look bigger if they went over to using 1000 and confused everything as it became difficult to tell which was used (plus you would buy a 100MB hard disk and windows would report its unformatted size as 80MB - then you'd wonder where the other 20MB had gone - had someone stolen it?

It is not as cut and dried as you think and KB being 1024Bytes is still well used in the industry even if you feel it is uncool.

In reply to a post by Andrue:

For most applications the hardware requirements are irrelevant. Very few programs stress a computer sufficiently to require the developer to give a damn. 8192kb or 10,000kb makes no odds. You use as much storage as suits your purposes and it either fits or it doesn't. If it doesn't fit (which is pretty damn' rare) it will be by such a magnitude of difference that a couple of mega bytes is neither here nor there.

Where I worked we spent a good deal of our time carving up application code and data areas into banks of memory that would fit into the addressing limits and still have the rights areas visible at the time each machine code in each of 50 odd threads was executed. Every last word of memory counted and debugging non-visibility problems was all part of the game where the trusty octalator was very much an essential tool as you pored over stacks of binary dumps with highlighter pen and strips of post-its to mark them up.

Edited by gomezz (Wed 30-Sep-09 09:11:23)

In reply to a post by ian72:

Someone had better tell Microsoft to stop using KB and MB the way they do then.

Why? Do you still regard Microsoft as the gold standard in the computer industry?

It has been the case for at least the 20 years I've been working in IT.

So what? Times change. 20 years ago software development was a fledgling industry. These days we're trying to be recognised as part of the wider engineering community and that means accepting more rigorous rules and adhering to the internationally agreed standards.

It is not as cut and dried as you think and KB being 1024Bytes is still well used in the industry even if you feel it is uncool.

I never said it was cut and dried and I certainly never implied it was 'uncool'.

Then some bright spark decided that their hard disks would look bigger if they went over to using 1000 and confused everything

Wrong.

http://en.wikipedia.org/wiki/Binary_prefix

"Hard disk drive manufacturers state capacity in decimal units. Unlike computer memory chips, disk drives have no addressing restrictions to force sector capacities to powers of two. This usage has a long tradition, even predating the SI system of decimal prefixes adopted in 1960, as follows"

The 'cool' factor is coming from people who think it's 'cool' to be different to everyone else. More sensible people can see that converting from powers of 2 values to those used everywhere else is a PITA that confuses people and impedes progress.

In reply to a post by gomezz:

In reply to a post by Andrue:

For most applications the hardware requirements are irrelevant. Very few programs stress a computer sufficiently to require the developer to give a damn. 8192kb or 10,000kb makes no odds. You use as much storage as suits your purposes and it either fits or it doesn't. If it doesn't fit (which is pretty damn' rare) it will be by such a magnitude of difference that a couple of mega bytes is neither here nor there.

Where I worked we spent a good deal of our time carving up application code and data areas into banks of memory that would fit into the addressing limits and still have the rights areas visible at the time each machine code in each of 50 odd threads was executed. Every last word of memory counted and debugging non-visibility problems was all part of the game where the trusty octalator was very much an essential tool as you pored over stacks of binary dumps with highlighter pen and strips of post-its to mark them up.

Oh aye, in the past. I remember doing that myself back in the late 90s. People developing software for embedded controllers likely still do.

But for most developers on most systems these days it's just a none-issue. Even if it were an issue most things simply don't fit into that scheme. It would be hugely wasteful to round everything up so that a power of two size was used. All it takes is for one item not to follow that rule and everything higher up memory is on a 'nuisance' boundary.

In fact with managed languages like Java and the .NET family the concept of a 'memory address' barely exists. Back when I was new to C# I tripped over that several times. Just because you have:

SomeClass sc=new SomeClass();

does not mean that 'sc' is a fixed numerical value. It can and likely will change without you knowing about it (objects get moved around over time as the garbage collector does its stuff). Anyone that has passed a 'pointer' from managed to unmanaged code will find that out the hardway. Even function pointers will change which is where I first fell into the trap. I passed the address of a static function into unmanaged code and when it tried to call it back it sometimes crashed. Turns out the static function wasn't always where I'd left it

In C++:

int f=(int)sc;

Is valid and only moderately stupid (mainly because of the loss of typing information). If you reverse that later and know what you're doing it's quite safe.

In C# it won't compile and is meaningless and very dangerous. Reversing it would result in undefined behaviour no matter when you did it.

Tempres fugit, I guess :-/

Where does OCTAL figure in all this then, I thought that apart from binary, on, off, computers were constrained by octal?

Edited by TrevorSP (Wed 30-Sep-09 14:21:19)

Octal notation was simply used as a shorthand way of writing down the value of 3 consecutive bits in computer memory, e.g (0)10110101 = 265 in octal. Octal might still be used in some UNIX systems.

With the advent of the 8-bit byte, hexadecimal notation became the norm, a "hex" digit (0-9, A-F) representing 4 bits, e.g 10110101 = B5 in hex.

Interesting, been in the game since 76 and learn something every day