Map #1813

Merged
merged 15 commits into from Jul 7, 2016

Conversation

Projects
None yet
3 participants
@kylebrandt
Member

kylebrandt commented Jul 5, 2016

still needs docs

@CheRuisiBesares

This comment has been minimized.

Show comment
Hide comment
@CheRuisiBesares

CheRuisiBesares Jul 6, 2016

Contributor

So with this would all math functions going forward operate on numberSets like abs? I have to read the code a little more but looking at your test that seems to be the direction. You like this direction better than making another type or something that works more like an interface in go. Im thinking something like models.Iterable where functions could take something like abs(Iterable) Iterable where math functions can never change the type ie do what reductions are doing. Im just wondering I think you tried that in another branch. I was wondering what your experience was there.

Contributor

CheRuisiBesares commented Jul 6, 2016

So with this would all math functions going forward operate on numberSets like abs? I have to read the code a little more but looking at your test that seems to be the direction. You like this direction better than making another type or something that works more like an interface in go. Im thinking something like models.Iterable where functions could take something like abs(Iterable) Iterable where math functions can never change the type ie do what reductions are doing. Im just wondering I think you tried that in another branch. I was wondering what your experience was there.

@kylebrandt

This comment has been minimized.

Show comment
Hide comment
@kylebrandt

kylebrandt Jul 6, 2016

Member

@CheRuisiBesares This does solve that issue as a side effect but has more power. For instance, you can abs(v) - v**2 etc...

This doesn't have to be independent of making those functions accept both, we could do that. When I tried I had issue getting the branch to work. I think that maybe It requires that the parser does additional lookaheads to know when the return type is going to be. I was having trouble pulling that off. Although maybe after going through this and understanding this part of the code more it would be easier.

Since we could still change math functions to take (and return, that is the harder part) multiple types down the road independently of map, what this effectively does is lower the priority on caring about that for now. When someone has some alerts to show that use a lot of these functions, and map is making it ugly as hell, then I think it would be better to figure out how to implement it at that point since we would have more user stories at that point.

Member

kylebrandt commented Jul 6, 2016

@CheRuisiBesares This does solve that issue as a side effect but has more power. For instance, you can abs(v) - v**2 etc...

This doesn't have to be independent of making those functions accept both, we could do that. When I tried I had issue getting the branch to work. I think that maybe It requires that the parser does additional lookaheads to know when the return type is going to be. I was having trouble pulling that off. Although maybe after going through this and understanding this part of the code more it would be easier.

Since we could still change math functions to take (and return, that is the harder part) multiple types down the road independently of map, what this effectively does is lower the priority on caring about that for now. When someone has some alerts to show that use a lot of these functions, and map is making it ugly as hell, then I think it would be better to figure out how to implement it at that point since we would have more user stories at that point.

@CheRuisiBesares

This comment has been minimized.

Show comment
Hide comment
@CheRuisiBesares

CheRuisiBesares Jul 6, 2016

Contributor

Good stuff! Makes sense to me. Excited to get my TI-89 on v**2 + v + 1

Contributor

CheRuisiBesares commented Jul 6, 2016

Good stuff! Makes sense to me. Excited to get my TI-89 on v**2 + v + 1

@captncraig

This comment has been minimized.

Show comment
Hide comment
@captncraig

captncraig Jul 6, 2016

Contributor

Looks ok to me.

Contributor

captncraig commented Jul 6, 2016

Looks ok to me.

@kylebrandt kylebrandt merged commit d602113 into master Jul 7, 2016

2 checks passed

bosun All checks Passed!
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@kylebrandt kylebrandt deleted the map branch Jul 26, 2016

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