why only int and int64

[JingShao Chen]

Hi,

In flag, strconv, there are functions to parse or convert int and
int64. Why not for other int type? say int32, int16?

Thanks,

[xf wang]

type Time struct {
    Year                 int64  // 2006 is 2006
    Month, Day           int    // Jan-2 is 1, 2
    Hour, Minute, Second int    // 15:04:05 is 15, 4, 5.
    Weekday              int    // Sunday, Monday, ...
    ZoneOffset           int    // seconds east of UTC, e.g. -7*60 for -0700
    Zone                 string // e.g., "MST"
}

Time.Year is int64,really needed?

[Evan Shaw]

Because making a function for every possible integer type is tedious
and clutters the interface. int and int64 are the most common cases.
For Itoa, you can always convert int16 and int32 to int with no loss
of precision. If you really need Atoi16, it's not too hard to write it
yourself.

- Evan

[JingShao Chen]

Yes, it is easy to convert or write my own.

However, just my thought, should the library cover the types since
they are predeclared in the lang spec?

Thanks!

On Sep 16, 9:32 am, Evan Shaw <chicken...@gmail.com> wrote:

[Anthony Tolle]

On Sep 16, 9:25 am, xf wang <wxf6...@gmail.com> wrote:
> Time.Year is int64,really needed?

Just wait until the year 2,147,483,648 rolls around. You'll see.

[Corey Thomasson]

The infamous Y2B bug.

[Russ Cox]

> Time.Year is int64,really needed?

That was probably a mistake on my part.
I had a reason (so that SecondsToUTC would
never need to return an error) but it's not a
very good reason.

Russ

[Alexis Shaw]

you never know how long your code will last, leave it as an int64, the memory wasted is 20%. I would say that you should have both be bigs.

[Alexis Shaw]

Then implement bigs really efficiently on small numbers.

[Russ Cox]

> you never know how long your code will last, leave it as an int64,

I don't know how long my code will last but
I think less than 2 billion years is more likely
than not.

Russ

[Alexis Shaw]

probably so, but the cost is not too great in any case.

[Clark Gaebel]

But there's no reason to pay it.

--
Regards,
-- Clark

[Alexis Shaw]

suppose not.

[Karl]

From the other side, Is there a true saving in memory if int8 and
int16 are used? The introduction of 32 bit processors into embedded
systems seems to imply that all int's are really stored as the width
of the cpu data flow so a 32bit cpu uses 32 bits and the C compiler
throws in a mask to truncate the value so it looks smaller. Also
going to 64 bit cpus in the PC world is not transparent. The point is
that 8 and 16 bit variables are really disguises for 32 bit variables,
add complexity to Go, and may get thrown away by the C compiler. int
and uint in C have caused issues because "C does not even know how
wide the variables are."

[Russel Winder]

Karl,

On Sat, 2010-09-18 at 06:02 -0700, Karl wrote:
> From the other side, Is there a true saving in memory if int8 and
> int16 are used? The introduction of 32 bit processors into embedded
> systems seems to imply that all int's are really stored as the width
> of the cpu data flow so a 32bit cpu uses 32 bits and the C compiler
> throws in a mask to truncate the value so it looks smaller. Also
> going to 64 bit cpus in the PC world is not transparent. The point is
> that 8 and 16 bit variables are really disguises for 32 bit variables,
> add complexity to Go, and may get thrown away by the C compiler. int
> and uint in C have caused issues because "C does not even know how
> wide the variables are."

I suspect you'll find that there are still huge numbers of 8051, AVR and
other 8-bit chips out there, the embedded world is far from universally
32-bit. Moreover just because the processor is 32-bit doesn't imply all
memory reads are 32-bit, they could be 8-, 16- or 32-bit. Since memory
reads are awfully slow compared to CPU operations, if you have 8-bit
data then using 8-bit ints makes sense even if the CPU then introduces
an extra 24-bits of data to do the actual calculation.

So basically even though in JVM 8-bit and 16-bit operations are actually
32-bit operations, this is not necessarily the case on real hardware.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[chris dollin]

On 18 September 2010 14:02, Karl <kw...@verizon.net> wrote:
> From the other side, Is there a true saving in memory if int8 and
> int16 are used?

Consider [K]int8 vs [K]int for largeish K.

--
Chris "allusive" Dollin

[Karl]

Thanks Chris. I wasn't really thinking about 8 bit arrays, now I
wonder what
they would be used for. Only good for small numbers, not for graphics
pixels or for
character strings. If the system has several gigs of memory, a couple
teras of hard
disk, I don't know how much virtual memory or how much graphics
memory. At some
size of K it would be significant.

Anyway you are right, simple arithmetic says there should be a factor
of 4 in the size.

[chris dollin]

On 19 September 2010 14:01, Karl <kw...@verizon.net> wrote:
> Thanks Chris.  I wasn't really thinking about 8 bit arrays, now I
> wonder what
> they would be used for.  Only good for small numbers, not for graphics
> pixels or for
> character strings.

Go strings are stored in (UTF-8 encoded) byte arrays.

Chris

--
Chris "allusive" Dollin

[David Roundy]

They're good for greyscale images, among other things

David

--
David Roundy

[Karl]

Thanks, Doctor.
Let me understand the point about slow memory reads. Are 32 bit reads
slower
than 8 bit reads or what? Are the number of memory reads different
for each
case?
The point that embedded is not all 32 bit is another reason that Go is
not for that
market and I am still wondering how much of the Go market needs int8.

> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net

> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@russel.org.uk
> London SW11 1EN, UK   w:www.russel.org.uk skype: russel_winder
>

>  signature.asc
> < 1KViewDownload

[chris dollin]

On 19 September 2010 14:06, chris dollin <ehog....@googlemail.com> wrote:
> On 19 September 2010 14:01, Karl <kw...@verizon.net> wrote:
>> Thanks Chris.  I wasn't really thinking about 8 bit arrays, now I
>> wonder what
>> they would be used for.  Only good for small numbers, not for graphics
>> pixels or for
>> character strings.
>
> Go strings are stored in (UTF-8 encoded) byte arrays.

Also int8 is useful in byte-coded interpreters.

--
Chris "allusive" Dollin

[Cory Mainwaring]

Int is supposed to be universal, in that it matches the base
architecture on bit-length. So if you're compiling for ARM, you get
the best sized int for ARM architecture, the same for x86 and x64. so
having that int should theoretically be all that one needs to be
portable and useful. The 64-bit version allows for high-magnitude
computing (the highest supported without arbitrary precision or a
custom type in Go).

As for int8, how heavy is the type-cast from int32 -> int8?

[Russel Winder]

Sorry for the long delay in replying to this.

On Sun, 2010-09-19 at 06:17 -0700, Karl wrote:

> Let me understand the point about slow memory reads. Are 32 bit reads
> slower
> than 8 bit reads or what? Are the number of memory reads different
> for each
> case?
> The point that embedded is not all 32 bit is another reason that Go is
> not for that
> market and I am still wondering how much of the Go market needs int8.

Some packagings of 32-bit processors use 8-bit external data buses and
byte structured memory systems -- probably less now but this was an
issue a short time back, especially in embedded systems. Reading an
8-bit entity is one read on such systems, whereas getting a 32-bit value
takes four reads. As reading from memory is a slow process this is
introducing extra delay and hence the utility of support for 8-bit and
16-bit instructions alongside the 32-bit instructions.

The follow up post though noted that the system of interest was a 32-bit
architectures with 32-bit memory and buses. In this case the 8-bit
issue I was raising is not an issue.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net