Comparison in numeric types from interface

[Archos]

The lacking of generic is maddening!!!

I've 2 fields (min, max) as interfaces since that they can have values
for different numeric types, but it cann't be used a comparison symbol
among them.

===
package main

func main() {
var min, max interface{}
min = 16
max = 1232

if max > min {
println("OK")
}
}
===
invalid operation: max > min (operator > not defined on interface)

[Robert Bloomquist]

Since interface{} can hold anything, how can you define equality, or inequality in this case?  Currently you have two integers, but what if one of them were a string?  Or a complex128?  Or an image.Image?  All of those satisfy interface{}, but you can't compare them.  If you cast them to a numeric type:

package main 

func main() { 
     var min, max interface{} 
     min = 16 
     max = 1232

     if m, ok := min.(int); !ok {

          panic("invalid type")

     }

     if n := max.(int); !ok {

          panic("invalid type")

     }

     if max > min { 
          println("OK") 
     } 
}

It should work, but it's probably not the solution you're looking for.

[R.wen Huang]

should be 

     if max.(int) > min.(int) { 
          println("OK") 
     } 

--
R.wen

[Paulo Pinto]

This is not really what generics are about.

The funny thing is that Go's percusor, Alef, had support for
parametrized data types.

http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref (chapter 4.8)

But alas, we might never see generics in Go.

--
Paulo

On Oct 8, 11:03 am, Robert Bloomquist <bloomquist.rob...@gmail.com>
wrote:

[Jan Mercl]

On Saturday, October 8, 2011 11:03:37 AM UTC+2, Robert Bloomquist wrote:

Since interface{} can hold anything, how can you define equality, or inequality in this case?  

Defined in the specs: http://golang.org/doc/go_spec.html#Comparison_operators

• Interface values are equal if they have identical dynamic types and equal dynamic values or if both are nil.
  
• An interface value x is equal to a non-interface value y if the dynamic type of x is identical to the static type of y and the dynamic value of x is equal to y.
• A pointer, function, slice, channel, map, or interface value is equal to nil if it has been assigned the explicit value nil, if it is uninitialized, or if it has been assigned another value equal to nil.

[Sebastien Binet]

hi,

(apologies if you get this twice, gmail failed me)

On Sat, 8 Oct 2011 05:06:27 -0700 (PDT), Paulo Pinto <paulo....@gmail.com> wrote:
> This is not really what generics are about.
>
> The funny thing is that Go's percusor, Alef, had support for
> parametrized data types.
>
> http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref (chapter 4.8)

interesting (especially the bound and unbound forms to instantiate such
templates)

as Go borrows so much (?) from Alef, anybody to chime in as to why
getting these parametric types might not be a good idea for Go as well ?
or how did they render Alef fragile/cumbersome/whatever ?

-s

[Rob 'Commander' Pike]

Alef's polymorphic types were an idea that never reached fruition. I don't even remember a first draft implementation being finished. They certainly never appeared in any production code I know of.

By the way, I wouldn't say Go borrows "so much" from Alef. They share an ancestor but not a direct lineage.

-rob

[Sebastien Binet]

On Sat, 8 Oct 2011 08:08:35 -0700, "Rob 'Commander' Pike" <r...@google.com> wrote:
>
> On Oct 8, 2011, at 7:00 AM, Sebastien Binet wrote:
>
> > hi,
> >
> > (apologies if you get this twice, gmail failed me)
> >
> > On Sat, 8 Oct 2011 05:06:27 -0700 (PDT), Paulo Pinto <paulo....@gmail.com> wrote:
> >> This is not really what generics are about.
> >>
> >> The funny thing is that Go's percusor, Alef, had support for
> >> parametrized data types.
> >>
> >> http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref (chapter 4.8)
> > interesting (especially the bound and unbound forms to instantiate such
> > templates)
> >
> > as Go borrows so much (?) from Alef, anybody to chime in as to why
> > getting these parametric types might not be a good idea for Go as well ?
> > or how did they render Alef fragile/cumbersome/whatever ?
>
> Alef's polymorphic types were an idea that never reached fruition. I
> don't even remember a first draft implementation being finished. They
> certainly never appeared in any production code I know of.

ah. too bad, having some experience via Alef would certainly have been
a valuable data point...

-s

[⚛]

Isn't it possible in your case to choose 1 numeric type (such as int,
int64, or float64) that has enough bits to represent 8-bit, 16-bit,
signed and unsigned, and any other values you are using?

If you need to store the numeric kind of the "min" and "max" values,
you can add an additional "kind" field:

type S struct {
min, max int64
kind Kind
}

type Kind int
const (
INT8 Kind = iota
INT16
UINT32
)

[Archos]

But the problem is that, in my case, it can get an unsigned (value),
or signed or float. So, i'd have to use at least 3 different kinds to
hold both minimum and maximum values --uint64, int64, float64--.

[⚛]

On Oct 8, 6:45 pm, Archos <raul....@sent.com> wrote:
> But the problem is that, in my case, it can get an unsigned (value),
> or signed or float. So, i'd have to use at least 3 different kinds to
> hold both minimum and maximum values --uint64, int64, float64--.

If you choose float64 it may be able to cover all *integer* values
that the program ever encounters during its run-time. Float64 has a
capacity of about 50 bits (http://en.wikipedia.org/wiki/
Double_precision_floating-point_format).

If the "min" and "max" values are linked to the amount of memory that
the program is spending, it is safe to use float64 if you expect the
program to consume less than 1000 terabytes of memory at any moment
during the program's lifetime (50 bits corresponds to 1000 terabytes).

If the full capacity of uint64 (all 64 bits) is needed, then of course
float64 cannot be used as a common numeric type.