[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