[J3] STORAGE_SIZE

[Malcolm Cohen]

I still think that as those machines use binary bits for storage, our current definition of STORAGE_SIZE works just fine for those machines.

 

And STORAGE_SIZE is inherently processor dependent anyway, as we don’t specify how many bits are used by storage.

 

That is, the standard “does not specify”... “the physical properties and implementation of storage”.

 

And so STORAGE_SIZE is returning a value that depends on something not specified by the standard. That’s a bit stronger even than “processor dependent”.

 

Perhaps STORAGE_SIZE does not work so well for the Fortran processor that is pencil+paper+person. How many bits in an A4 page (if the person uses one page for each array element)? I find this example more motivating than a machine that used binary storage anyway.

 

We could say something like “If storage of a variable cannot be measured in bits, the value returned is the number of bits needed to represent every possible internal state of that storage.” That’s what I would understand the current text to mean anyway – it’s like “as if it were measured in bits”.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
Sent: Tuesday, October 13, 2020 8:07 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Robert Corbett <rpcorbett at att.net>
Subject: Re: [J3] STORAGE_SIZE

 

I agree that there is no need to

support such machines.  If we

do not, we should say we do not.

 

The IBM 1620 used six bits to

store one decimal digit, a flag,

and a parity bit.  The flag bit

could be a sign bit or a

field terminator.  Not all

combinations of bits were

allowed.  Some special bit

sequences had special

properties, and others were

not used at all during normal

execution.  The four bits used

to represent a decimal digit

could not represent the

values 10 - 15, which limits

their use for bitwise operations.

 

Robert Corbett


On Oct 13, 2020, at 12:51 AM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> > wrote:

I don’t think those machines are coming back, so it’s hard to feel too worried about this kind of thing...

 

And they are not decimal machines for storage. They are binary, with (if I read the doc correctly) eight bits per location, though one of those bits is parity. STORAGE_SIZE should return the number of bits of storage...

 

I’m not seeing a problem here, but maybe I’m not looking hard enough.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: J3 <j3-bounces at mailman.j3-fortran.org <mailto:j3-bounces at mailman.j3-fortran.org> > On Behalf Of Robert Corbett via J3
Sent: Tuesday, October 13, 2020 3:29 PM
To: j3 at j3-fortran.org <mailto:j3 at j3-fortran.org> 
Cc: Robert Corbett <rpcorbett at att.net <mailto:rpcorbett at att.net> >
Subject: [J3] STORAGE_SIZE

 

The intrinsic function
STORAGE_SIZE returns the
size of an array element in
bits. Machines such as the
IBM 1401 and the IBM 1620
stored data as decimal
digits instead of bits. Should
we say that STORAGE_SIZE
is processor dependent on
such machines?

Robert Corbett




Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201014/5eceae3a/attachment-0001.htm>