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

Java/Javascript split questions #424

Open
vandyxiaowei opened this issue May 11, 2024 · 2 comments
Open

Java/Javascript split questions #424

vandyxiaowei opened this issue May 11, 2024 · 2 comments

Comments

@vandyxiaowei
Copy link
Contributor

  1. can we show the detailed scores for Java/Javascript splits on the leaderboard (instead of the averaged Simple function)? One observation I have from running the benchmark myself is that Prompt model seems to have more advantages over FC endpoints.
  2. for Java types (Array/ArrayList/Hashmap), from the parsing code here:
    elif expected_type == "Array" or expected_type == "ArrayList":
    are we expecting the parameter values are in the form of "new ArrayList", "new HashMap", etc. I think usually users' expectations on FC endpoint outputs (not Prompt) are JSON object.

Thanks!

@HuanzhiMao
Copy link
Collaborator

HuanzhiMao commented May 11, 2024

Hi @vandyxiaowei,

Regarding your first question:
Good point. We will display the detailed score breakdown of the AST Simple category in the next website release (likely next week on May 16/17).

Regarding your second question:
Yes, we are expecting values in the format of new ArrayList; it needs to be valid Java syntax, and a JSON list [] would not be correct.
For Java (and JavaScript as well), before querying the model, we do some pre-processing on the prompt and function document. Specifically, at the end of the prompt, we will explicitly state that the provided function is in Java 8/JavaScript/Python syntax. And for parameter types that are not native to JSON, we will change their type to String (since String is JSON compatible) and add in the parameter description that "This is Java/Javascript" + {original_type} + " in string representation."
So in the example you provided above, when expecting type ArrayList, model will get the instruction that this is a String type parameter with the parameter description containing "This is Java ArrayList in string representation.", and thus the model should output the value in String format (eg, "new ArrayList<>(Arrays.asList(10, 20, 30))"), which is JSON compatible.
The relevant code that handles the pre-processing is here.

Let me know if you have more questions!

@GeniusYx
Copy link

GeniusYx commented Jul 1, 2024

Hi~,can we show the detailed scores for Java/Javascript splits on the leaderboard (instead of the averaged Simple function)?
Thanks!

ShishirPatil pushed a commit that referenced this issue Jul 22, 2024
…est Category (#538)

In our BFCL official communication channels, including the evaluation
manual blog, GitHub issue replies (such as #424), and our Discord
channel, we have previously stated the following:

> For Java and JavaScript test category, before querying the model, we
do some pre-processing on the prompt and function document.
Specifically, at the end of the prompt, we will explicitly state that
`the provided function is in Java 8/JavaScript/Python syntax`. And for
parameter types that are not native to JSON, we will change their type
to `String` (since `String` is JSON compatible) and add in the parameter
description that `f" This is Java/JavaScript {value['type']} in string
representation."`
> As an example, when expecting type `ArrayList`, model will get the
instruction that this is a `String` type parameter with the parameter
description containing `"This is Java ArrayList in string
representation."`, and thus the model should output the value in
`String` format (eg, `"new ArrayList<>(Arrays.asList(10, 20, 30))"`),
which is JSON compatible.

However, the code for `language_specific_pre_processing` did not
implement this correctly. Due to an indentation issue, the parameter
description was only modified when the parameter type was `any`, and the
part where the parameter type is cast to `String` was never implemented.

This issue was unnoticed until PR #516 was merged because of the
double-casting problem.

It *significantly impacts* the evaluation score for the Java and
JavaScript categories. We will update the leaderboard very soon.

This PR:
- Addresses the above issue and ensures that the evaluation logic aligns
with the previously described behaviour
- Updates two entries in the JavaScript dataset, due to their parameters
missing a `description` field
  - Index: `14, 45`

We sincerely apologize for the oversight.
aw632 pushed a commit to vinaybagade/gorilla that referenced this issue Aug 22, 2024
…est Category (ShishirPatil#538)

In our BFCL official communication channels, including the evaluation
manual blog, GitHub issue replies (such as ShishirPatil#424), and our Discord
channel, we have previously stated the following:

> For Java and JavaScript test category, before querying the model, we
do some pre-processing on the prompt and function document.
Specifically, at the end of the prompt, we will explicitly state that
`the provided function is in Java 8/JavaScript/Python syntax`. And for
parameter types that are not native to JSON, we will change their type
to `String` (since `String` is JSON compatible) and add in the parameter
description that `f" This is Java/JavaScript {value['type']} in string
representation."`
> As an example, when expecting type `ArrayList`, model will get the
instruction that this is a `String` type parameter with the parameter
description containing `"This is Java ArrayList in string
representation."`, and thus the model should output the value in
`String` format (eg, `"new ArrayList<>(Arrays.asList(10, 20, 30))"`),
which is JSON compatible.

However, the code for `language_specific_pre_processing` did not
implement this correctly. Due to an indentation issue, the parameter
description was only modified when the parameter type was `any`, and the
part where the parameter type is cast to `String` was never implemented.

This issue was unnoticed until PR ShishirPatil#516 was merged because of the
double-casting problem.

It *significantly impacts* the evaluation score for the Java and
JavaScript categories. We will update the leaderboard very soon.

This PR:
- Addresses the above issue and ensures that the evaluation logic aligns
with the previously described behaviour
- Updates two entries in the JavaScript dataset, due to their parameters
missing a `description` field
  - Index: `14, 45`

We sincerely apologize for the oversight.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants