[M3devel] INTEGER

Mika Nystrom mika at async.async.caltech.edu
Tue Apr 20 02:09:58 CEST 2010


Jay K writes:
>--_747381e9-b91f-4765-9877-7c09d53c76c7_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
> > Modula-3 already uses floating point for this=2C which has the advantage
> > you don't need to worry what the base is.=20
>
>=20
>
>What do you mean not worry about the "base"?
>
>I'm not a fan of floating point.

If you use integer counts of some small interval, that small interval
is what I mean has to be specified somewhere.

There's nothing much wrong with floating point.  It works fine and Time.T
can certainly represent intervals much smaller than a second using any
reasonable epoch (almost the age of the universe, I think).

>
>=20
>
>=20
>
>> support. The reason I don't like LONGINT as much is that it seems it's
>> just a waste if we're all going to be using 64-bit machines anyhow.
>
>
>=20
>
>Again=2C you might be right. C got 64bit integers ~18 years ago. We are lat=
>e.
>
>Do you think phones and embedded devices will move to 64bits soon too?
>
>Are gaming consoles 64bits?

No, but again the fact that C does something is not a good reason for us to do
it.  We need a new language type just to deal with file lengths?  I think not.
That's the only real use case I've seen so far...?

>
>Again=2C aside=2C can such an array be made truly abstract?
>
>   I'd like opaque data structures without forcing heap allocation.
>
>Because=2C you know=2C it is somewhat tricky how to deal with=2C and people
>
>will differ as to their assumptions of the order of the integers.
>

Of course it has to be little endian.

    Mika



More information about the M3devel mailing list