You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, you have to specify the value as being specifically a float, as javac won't coerce a double to a Float, for use with both temperature and topP. However, in the serialized form being sent to the LLMs, the granularity and format aren't different; the options object is slightly larger with the use of Double instead of Float but that's unlikely to be significant, and it's less confusing for programmers to use the natural syntax for doubles over the syntax for floats. The following code is what one has to do now, if one sets the temperature, for example:
It hasn't really affected me - I mean, I guess I have to type that f or use a Float reference instead, oh the humanity, etc.. but I think it's a relatively appropriate change for quality of life for users of the APIs, and the impact for current users would be minimal since it's a widening operation and not a narrowing one.
The text was updated successfully, but these errors were encountered:
Please do a quick search on GitHub issues first, the feature you are about to request might have already been requested.
Expected Behavior
Current Behavior
Right now, you have to specify the value as being specifically a
float
, as javac won't coerce adouble
to aFloat
, for use with bothtemperature
andtopP
. However, in the serialized form being sent to the LLMs, the granularity and format aren't different; the options object is slightly larger with the use ofDouble
instead ofFloat
but that's unlikely to be significant, and it's less confusing for programmers to use the natural syntax for doubles over the syntax for floats. The following code is what one has to do now, if one sets thetemperature
, for example:Context
It hasn't really affected me - I mean, I guess I have to type that
f
or use aFloat
reference instead, oh the humanity, etc.. but I think it's a relatively appropriate change for quality of life for users of the APIs, and the impact for current users would be minimal since it's a widening operation and not a narrowing one.The text was updated successfully, but these errors were encountered: