Skip to content
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

drop() by default? #39

Open
RobinHankin opened this issue Sep 12, 2020 · 4 comments
Open

drop() by default? #39

RobinHankin opened this issue Sep 12, 2020 · 4 comments
Labels
enhancement New feature or request infelicity not quite a bug, but an...infelicity

Comments

@RobinHankin
Copy link
Owner

Most of the time I want the drop()ed value:

> e(1)^2
Element of a Clifford algebra, equal to
scalar ( 1 )
> drop(e(1)^2)
[1] 1
> 

Maybe drop() should be called by default to eliminate this needless repetition. Maybe it should be an option()?

@RobinHankin RobinHankin added enhancement New feature or request infelicity not quite a bug, but an...infelicity labels Sep 12, 2020
@RobinHankin
Copy link
Owner Author

RobinHankin commented Sep 12, 2020

Also, equality testing is infelicitous:

> e(1)^2 == 1
Error in Ops.clifford(e(1)^2, 1) : 
  Generic '==' only compares two clifford objects with one another
> drop(e(1)^2)  == 1
[1] TRUE
> 

@RobinHankin
Copy link
Owner Author

Simply changing the last line of clifford() from return(out) to return(drop(out)) is not a good idea: it requires a Kafkaesque sequence of code changes because quite often you actually want a scalar to be a Clifford object

@RobinHankin
Copy link
Owner Author

RobinHankin commented Sep 13, 2020

The problem with the earlier suggestion of adding return(drop(out)) to the end of clifford() is this: I want idiom 4 + e(1) to work. Currently this is done by coercing the 4 to a clifford, then dispatching to clifford_plus_clifford(). But the suggestion makes as.clifford(4) return numeric 4, and so the clifford addition fails:

> clifford_plus_clifford(4,e(1))
Error in x[[2]] : subscript out of bounds
> 

RobinHankin added a commit that referenced this issue Sep 13, 2020
@RobinHankin
Copy link
Owner Author

There are a few functions in the package that should have a drop argument added; see also issue #59.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request infelicity not quite a bug, but an...infelicity
Projects
None yet
Development

No branches or pull requests

1 participant