New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add float math functions to standard library #374

Closed
andrewrk opened this Issue May 20, 2017 · 14 comments

Comments

Projects
None yet
3 participants
@andrewrk
Member

andrewrk commented May 20, 2017

Functions:

  • fma
  • nan
  • abs
  • exp
  • exp2
  • loge
  • log2
  • log10
  • sqrt
  • cbrt
  • hypot
  • pow
  • sin
  • cos
  • tan
  • asin
  • acos
  • atan
  • atan2
  • sinh
  • cosh
  • tanh
  • asinh
  • acosh
  • atanh
  • ceil
  • floor
  • trunc
  • round
  • scalbn
  • isfinite
  • isinf
  • isnan
  • isnormal
  • signbit

Constants:

  • e
  • pi

There is also a concept of floating point exceptions which libc lets you query after you do a floating point operation. To be considered if we want to support something like that.

@tiehuis

This comment has been minimized.

Show comment
Hide comment
@tiehuis

tiehuis May 26, 2017

Member

I'm slightly interested in this. I've had a bit of a look so far. The following are decent references for implementation (most share some common history):

One question I had was regarding the handling of the multiple float types. libc for example has separate calls for float, double and long doubles in most places. This seems over the top for the moment and the go math library appears to forgo any explicit f32 routines and just implements f64 functions. This suggests at least that the simplistic upcasting approach doesn't have any glaring problems.

Member

tiehuis commented May 26, 2017

I'm slightly interested in this. I've had a bit of a look so far. The following are decent references for implementation (most share some common history):

One question I had was regarding the handling of the multiple float types. libc for example has separate calls for float, double and long doubles in most places. This seems over the top for the moment and the go math library appears to forgo any explicit f32 routines and just implements f64 functions. This suggests at least that the simplistic upcasting approach doesn't have any glaring problems.

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk May 26, 2017

Member

My plan was to have zig automatically dispatch to the correct floating point function based on the type. You can see an example with the floor function in std/math.zig.

Member

andrewrk commented May 26, 2017

My plan was to have zig automatically dispatch to the correct floating point function based on the type. You can see an example with the floor function in std/math.zig.

@tiehuis

This comment has been minimized.

Show comment
Hide comment
@tiehuis

tiehuis May 26, 2017

Member

Makes sense. I'll use that method when experimenting with this.

Member

tiehuis commented May 26, 2017

Makes sense. I'll use that method when experimenting with this.

@thejoshwolfe

This comment has been minimized.

Show comment
Hide comment
@thejoshwolfe

thejoshwolfe May 26, 2017

Member

am i correct in guessing that all of the listed functions are float-in and/or float-out? this would be in contrast to integer math functions like gcd, isprime, or sign (sometimes).

Member

thejoshwolfe commented May 26, 2017

am i correct in guessing that all of the listed functions are float-in and/or float-out? this would be in contrast to integer math functions like gcd, isprime, or sign (sometimes).

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk May 26, 2017

Member

Yes I believe these are all float functions, and the result is the same type as the input.

Side note, I think that go ignores f32 and only has f64 because it lacks generics and this was a way around that.

Member

andrewrk commented May 26, 2017

Yes I believe these are all float functions, and the result is the same type as the input.

Side note, I think that go ignores f32 and only has f64 because it lacks generics and this was a way around that.

@thejoshwolfe thejoshwolfe changed the title from add math functions to standard library to add float math functions to standard library May 26, 2017

@tiehuis

This comment has been minimized.

Show comment
Hide comment
@tiehuis

tiehuis May 27, 2017

Member

Made a repository here for the moment: https://github.com/tiehuis/zig-fmath

Member

tiehuis commented May 27, 2017

Made a repository here for the moment: https://github.com/tiehuis/zig-fmath

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk May 29, 2017

Member

Wow nice work @tiehuis. I'll have a look at these and try to get some nice test cases going.

Member

andrewrk commented May 29, 2017

Wow nice work @tiehuis. I'll have a look at these and try to get some nice test cases going.

@tiehuis

This comment has been minimized.

Show comment
Hide comment
@tiehuis

tiehuis May 30, 2017

Member

One thing I was considering regarding test-cases was to just export the functions under their c equivalents and link against the libc-test cases here.

That being said, the differences between how errors are flagged and the rest could make this not completely straightforward and it may be easier just to rewrite these under zig.

Member

tiehuis commented May 30, 2017

One thing I was considering regarding test-cases was to just export the functions under their c equivalents and link against the libc-test cases here.

That being said, the differences between how errors are flagged and the rest could make this not completely straightforward and it may be easier just to rewrite these under zig.

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk May 30, 2017

Member

That's a good idea. Another idea is to port the test cases to zig test. Should be pretty straightforward. If the test files are big they can go in different file that doesn't get installed with the standard library.

Member

andrewrk commented May 30, 2017

That's a good idea. Another idea is to port the test cases to zig test. Should be pretty straightforward. If the test files are big they can go in different file that doesn't get installed with the standard library.

@tiehuis

This comment has been minimized.

Show comment
Hide comment
@tiehuis

tiehuis Jun 11, 2017

Member

An initial implementation of this is currently complete here. There are various edge cases that are currently unimplemented and still needs some improvement and tests, but the initial conversion to zig is complete at least.

See tiehuis/zig-fmath#7 for some discussion questions about some improvements.

Member

tiehuis commented Jun 11, 2017

An initial implementation of this is currently complete here. There are various edge cases that are currently unimplemented and still needs some improvement and tests, but the initial conversion to zig is complete at least.

See tiehuis/zig-fmath#7 for some discussion questions about some improvements.

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk Jun 11, 2017

Member

This is an incredibly huge contribution to zig @tiehuis. 🎉

Would you like to become a member of the zig-lang organization and have commit access?

Member

andrewrk commented Jun 11, 2017

This is an incredibly huge contribution to zig @tiehuis. 🎉

Would you like to become a member of the zig-lang organization and have commit access?

@tiehuis

This comment has been minimized.

Show comment
Hide comment
@tiehuis

tiehuis Jun 12, 2017

Member

Sure! That would be much appreciated.

I'll merge these changes into a branch shortly once I've finalized some minor details. I would like to extend the test suite slightly before merging in to zig proper, but may as well tie into the existing test suite in another branch in one go.

Member

tiehuis commented Jun 12, 2017

Sure! That would be much appreciated.

I'll merge these changes into a branch shortly once I've finalized some minor details. I would like to extend the test suite slightly before merging in to zig proper, but may as well tie into the existing test suite in another branch in one go.

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk Jun 14, 2017

Member

I believe you should have write access to all the zig-lang repos now.

I went ahead and merged my partial port of errol3 floating point printing, since it didn't break the tests. It includes an implementation of @bitCast. Feel free to delete the partial code I ported from zig-fmath when you want to do the full merge.

Member

andrewrk commented Jun 14, 2017

I believe you should have write access to all the zig-lang repos now.

I went ahead and merged my partial port of errol3 floating point printing, since it didn't break the tests. It includes an implementation of @bitCast. Feel free to delete the partial code I ported from zig-fmath when you want to do the full merge.

tiehuis added a commit that referenced this issue Jun 16, 2017

Add math library
This covers the majority of the functions as covered by the C99
specification for a math library.

Code is adapted primarily from musl libc, with the pow and standard
trigonometric functions adapted from the Go stdlib.

Changes:

 - Remove assert expose in index and import as needed.
 - Add float log function and merge with existing base 2 integer
   implementation.

See https://github.com/tiehuis/zig-fmath.
See #374.

@andrewrk andrewrk modified the milestones: 0.1.0, 0.2.0 Jun 16, 2017

@andrewrk

This comment has been minimized.

Show comment
Hide comment
@andrewrk

andrewrk Jun 16, 2017

Member

Scheduling for 0.1.0 because @tiehuis has this all very close to completion.

Member

andrewrk commented Jun 16, 2017

Scheduling for 0.1.0 because @tiehuis has this all very close to completion.

@andrewrk andrewrk closed this in 3e8af78 Jun 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment