Possible factorial error.

[a35joshi]

Hi.
I am not sure about this being a bug or not but I will put forward some of my findings.
So I defined the factorial method as given on [(http://www.objecthunter.net/exp4j/)].
I get an exception for 3!-2! but not for 3-2!(I get 1, as expected). But rightfully, (3!)-(2!) gives me the correct answer(i.e, 4).
What can be done in order for 3!-2! to work without having to enter brackets?

[dktcoding]

Yes, this actually related to #64 see pull request #74, I just added a test for this and it seems to be resolved in that branch (https://travis-ci.org/dktcoding/exp4j/builds/182453474)

[a35joshi]

case '!': if (numArguments != 1) { return BUILTIN[INDEX_FACTORIAL]; } default: return null; This is the proposed fix correct? In this, would the numArguments be number of elements in the string to which I add operators and numbers?

…

________________________________ From: Federico Vera <[email protected]> Sent: Friday, December 9, 2016 5:43 AM To: fasseg/exp4j Cc: Anurag Joshi; Author Subject: Re: [fasseg/exp4j] Possible factorial error. (#75) Yes, this actually related to #64<#64> see pull request #74<#74>, I just added a test for this and it seems to be resolved in that branch (https://travis-ci.org/dktcoding/exp4j/builds/182453474) - You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#75 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQCtmLEEqwNlKGz4vZUp1KvjRfWys_rWks5rGJ0vgaJpZM4LIbDd>.

[dktcoding]

That's the special casing, the way it works is:

1. The ! is declared to have only one argument (as it should)
2. Since we need ! to be always on the right we treated as a binary operator with a null second argument (like num!null)
3. The tokenizer doesn't actually count the number of available tokens, it uses some clever assumptions to try and figure out the argument count.
4. Based on (3) we could trick it to believe that it should have two arguments when there's only one is available, that way the expression is always valid (because it has only one argument), but the operator is always on the right.

The problem is that this can't be done using an external Operator (at least I was unable to figure out how), only using a built-in so it's possible to special case it

That code you posted isn't from the original exp4j it's from a fork I created, the proposed fix is detailed in PR #74

[fasseg]

Hey Guys,
I do have January off and will invest some time to get exp4j up to date. Unfortunately I do not have enough time to do this properly earlier...

[fasseg]

Hey Guys,

I added the tests from @dktcoding and it does produce the correct values. Am I missing something there or has this bug mysteriously disappeared?
Commmit: e977f19