math package

[Gabor]

Functions in the math package expect float64 arguments.
So the following simple code does not work, because x,y are floats:
x := 2.0
y := 3.0
z := math.Pow(x,y)
Is there a workaround or any plan to add new functions?
Or is this a question leading to the question of generics?

[Daniel Smith]

You can do conversions:

x := float64(2)
y := float64(3)
z := math.Pow(x,y)

Or you can have the compiler do it for you:

var x float64

var y float64
x = 2
y = 3
z := math.Pow(x,y)

--
Daniel Smith
http://www.schaumburggoclub.org/

[Gabor]

And something more serious. Say, you want to write a Fourier
transform, but float32 precision would suffice. With the present math
package one is forced to do everything in float64 precision as there
are no trigonometric functions of lower precision.

So the other question is:
Are there any plans to implement these at some point?

[Gabor]

Thanks for your help and prompt answer, but both solutions bring extra
typing that does not seem to be significant in this simplistic
example, but in real computational code can quickly become a pain in
the neck. In this situation Go looses a lot from its attractive
features.

On May 26, 8:42 pm, Daniel Smith <dan...@lukenine45.net> wrote:

[Beoran]

You might want to write a wraper a package mathf that wraps all math
functions for use with float variables.
Then import it using math, and it should solve your problem.

Kind Regards,

Bjorn.

[Gabor]

I think this is such a general task that should not require wrappers.
But even so, a native math function with float64 arguments
will always be slower than a math function with float32 arguments.
For scientific calculations speed is really important.

[John Asmuth]

On May 26, 3:48 pm, Gabor <g...@szfki.hu> wrote:
> a native math function with float64 arguments
> will always be slower than a math function with float32 arguments.

[citation needed]

[emghazal]

On 32-bit systems, they are. But I'm not sure about 64-bit systems.

[Russ Cox]

>> >  a native math function with float64 arguments
>> > will always be slower than a math function with float32 arguments.
>>
>> [citation needed]
>
> On 32-bit systems, they are. But I'm not sure about 64-bit systems.

Go runs on x86-32, x86-64, and ARM. Most ARM chips don't
even have floating point, and the x86-32 and x86-64 have no
distinct 32-bit intrinsic instructions. The only way I can see to
get a 32-bit sin, cos, or sqrt would be to change the floating point
register precision with a mode flip. The cost of that mode flip
would more than dwarf any speedup that could be gained from
doing a less precise computation.

Russ

[emghazal]

Oh right. I forgot this is about floating point, not integers. Mea
culpa.

[Gabor]

On May 27, 7:59 am, Russ Cox <r...@golang.org> wrote:

> Go runs on x86-32, x86-64, and ARM. Most ARM chips don't
> even have floating point, and the x86-32 and x86-64 have no
> distinct 32-bit intrinsic instructions. The only way I can see to
> get a 32-bit sin, cos, or sqrt would be to change the floating point
> register precision with a mode flip. The cost of that mode flip
> would more than dwarf any speedup that could be gained from
> doing a less precise computation.

Thanks for your answer, I did not know this.

Maybe I remember incorrectly, so I have to test again the anticipated
speedup when switching from 8-byte to 4-byte floating point numbers.

My first question remains:
With the present math package that expects float64 arguments
is there a way to use the elegant x := 2.0 style variable assignments
without declaring var x float64 or use explicit float64(2.0)
conversions.

[Sonia Keys]

On May 27, 5:27 am, Gabor <g...@szfki.hu> wrote:

> My first question remains:
> With the present math package that expects float64 arguments
> is there a way to use the elegant x := 2.0 style variable assignments
> without declaring  var x float64  or use explicit float64(2.0)
> conversions.

Pretty sure the answer is no.

In sympathy, I do agree it's awkward that this particular default in
short declarations is not well supported by the math package. I'm
optimistic, though, that this will be resolved by the addition of some
sort of generics at some point, that would allow people to work more
easily in whatever type they choose, for whatever reasons.

In support of the current language and libraries, I'm okay with the
way things are. If an early library is going to support one type
well, it has to float64. As long as all the conversions are in place,
it's enough. The short declarations are controversial, if you review
the posts and issues. I like them, but I think of them as a way to
save typing for some common situations, and not as something that
"should work" in all cases. They have default behavior, and like
defaults in anything, kind of by definition, if you don't want the
default, you must specify otherwise. I'm okay writing,

var x float64 = 2

(and actually happy I don't have to say 2., 2.0, 2d0, etc.)

[roger peppe]

i was slightly surprised the language provides "float" at all.
almost nothing uses it.

they could make the default float64 and remove float
without harming anyone particularly.

[Ian Lance Taylor]

roger peppe <rogp...@gmail.com> writes:

> i was slightly surprised the language provides "float" at all.
> almost nothing uses it.
>
> they could make the default float64 and remove float
> without harming anyone particularly.

I think that is worth considering.

The only real downside I can see is that there are a few processors
which only natively support 32-bit floating point operations. Of
course Go doesn't currently work on those processors, and it may not
be worth worrying about.

Ian

[Gabor]

The math package is critical for a general-purpose language
focusing on efficiency and ease of development.

As a plain user (not a computer scientist) I did not
and do not dare to suggest to get rid of the numeric type float.
But it is obvious that the number type float and the
math package with float64 arguments do not match well.

As for the efficiency of math functions with float64 vs float32
arguments I still do not see clearly, and would greatly appreciate
further comments from the developers.
Using Intel Core 2 duo processors with 32 or 64 bit operating systems
Fortran math functions or the famous FFTW library written in C
always give me a factor of 2 speedup when I switch

from 8-byte to 4-byte floating point numbers.

I still do not understand why this could not be acheived
for the language Go at some point. Not now, but at some point.

On May 27, 7:33 pm, Ian Lance Taylor <i...@google.com> wrote:

[Russ Cox]

> Using Intel Core 2 duo processors with 32 or 64 bit operating systems
> Fortran math functions or the famous FFTW library written in C
> always give me a factor of 2 speedup when I switch
> from 8-byte to 4-byte floating point numbers.

This has nothing to do with the math library.
FFTW isn't calling sin or cos repeatedly.
The win there is the use of packed instructions
that can interpret one or two 64-bit values as
two or four 32-bit values and get twice as much
work done in the same number of instructions.
But that's an assembly-level concern, and
you can hook up extra assembly routines to
Go as easily as you can hook them up to C.
The size of the math library functions does not
affect this.

Russ

[Gabor]

On May 27, 11:49 pm, Russ Cox <r...@golang.org> wrote:
> This has nothing to do with the math library.
> FFTW isn't calling sin or cos repeatedly.
> The win there is the use of packed instructions
> that can interpret one or two 64-bit values as
> two or four 32-bit values and get twice as much
> work done in the same number of instructions.
> But that's an assembly-level concern, and
> you can hook up extra assembly routines to
> Go as easily as you can hook them up to C.
> The size of the math library functions does not
> affect this.

Forgive me, but I still cannot get this.
Maybe it is more straightforward to consider
C89 vs C99 languages instead of the FFTW library.

Originally, C89 had only math functions with double arguments.
C99 added two new versions, one for float and one for long double.
For me this tells that speed and accuracy are also library issues.
I am totally confused.

[Ian Lance Taylor]

Gabor <g...@szfki.hu> writes:

> Originally, C89 had only math functions with double arguments.
> C99 added two new versions, one for float and one for long double.
> For me this tells that speed and accuracy are also library issues.
> I am totally confused.

There are indeed processors for which 32-bit floating point operations
are faster than 64-bit floating point operations. There are even
processors which implement 32-bit operations in hardware but implement
64-bit operations in software. The Go math library is not optimal for
those processors. But then, the Go compilers don't support them
either.

Ian

[Gabor]

I summarize and stop here.

Question 1.
The elegant x := 2.0 assignment gives us a float
that cannot be directly used in math functions
expecting float64 arguments. Of course x can
declared to be float64 or converted to float64
but these solutions are significantly more verbose.
I still see some room for improvement to make
a better match of floats and the math package.
Roger Peppe even suggested the removal of the type
float, that was not rejected by Ian Lance Taylor.

Question 2.
The math package is written only for float64 arguments.
I was worried about calculation speed in those cases
when float32 arguments would be enough for accuracy.
Russ Cox and Ian Lance Taylor explained in detail
that this is not a math library issue, because Go
is implemented only on such processor architectures
where the hardware is not faster for 32-bit operations.
Furthermore, in cases like the FFTW library
the observed speedup comes from the use SSE instructions.
These explanations are logical, so I have to recheck various
OS/language/compiler/compiler_switch combinations.

Thank you for all your answers and patience.

[Magnificence]

On May 28, 5:57 pm, Ian Lance Taylor <i...@google.com> wrote:
> There are indeed processors for which 32-bit floating point operations
> are faster than 64-bit floating point operations.

And that's why I think float as a type should stay, if it will be
considered to be removed. I currently are working on a lightweight
graph control in C++. I'm using a lot of floating point arithmetic in
there. Mostly I use float instead of doubles to improve speed, but if
doubles where as fast as floats, I could use doubles. If in Go float
would be 32-bit on the systems that are faster with 32-bit floating
point operations and visa versa for 64-bit floating point operations,
then I could just use float in the situation of the graph control,
because I just need the fastest one, but if a bigger one is available
which is just as fast, I'd like to use that one.

[Michael Jones]

Commenting on Gabor's mention of FFTW...

Big FFTs have the special attribute that the cost of processing is influenced BOTH by global memory/cache interactions and a SIMD-style computational kernel. Based on the stronger area of hardware advantage that a particular computing system displays, FFTW selects a different, size-dependent approach to exploit that benefit after timing runs of all possible approaches to prove an empirically optimal solution under all combinations of compiler options. The author of FFTW, Matteo Frigo, has been someone I've known and respected since his MIT days. FFTW is somewhat beyond the ordinary 32/64 bit fp question. 

Also, 32-bit fp is terrible. The dynamic range is too small. The mantissa is too coarse. FP contagion comes on too quickly. It is not akin to small integers. An 8-bit counter is as perfect up to 255 as would be a 128-bit counter. This is not the case for 32-bit FP.

Michael

--

Michael T. Jones

   Chief Technology Advocate, Google Inc.

   1600 Amphitheatre Parkway, Mountain View, California 94043

   Email: m...@google.com  Mobile: 650-335-5765  Fax: 650-649-1938

   Organizing the world's information to make it universally accessible and useful

[Paulo Pinto]

What about doing like in C and having 32 and 64 bit versions
available?