Re: [commons-lang] Util function in NumberUtils to count significant figures in a numeric string
Im am currently using that API for unit conversion. Don't remember seeing anything related to uncertainty or precision. I'll double check, but IIRC it's focused very much on just unit conversion. On Thu, Aug 10, 2023, 9:40 PM Gary Gregory wrote: > See also JSR-363 https://jcp.org/en/jsr/detail?id=363 > > Gary > > On Thu, Aug 10, 2023, 10:56 AM Daniel Watson wrote: > > > I brought this up in commons-math and it was determined that that > probably > > wasn't a good place for it, as that lib focuses on computational > functions. > > It was also mentioned that commons-numbers was not a great place for the > > static util method either. > > > > Essentially the need for this relates to scientific measurements. > > Measurements are often reported with implied precision and uncertainty > > (e.g. 0.0015 has 2 significant figures, 1.10 has 3, etc). Currently there > > are no Number classes that retain or respect this information. There are > > widely accepted conventions for how to retain and adjust both precision > and > > uncertainty during mathematical operations. But the first step is simply > > knowing what those two values are. I propose a util method (already > > written) in NumberUtils that can do this. The conventions are widely > > documented but would be spelled out very specifically in the javadoc. > > Although NumberUtils mainly focuses on pure math transformation, it does > > also include some parsing, so this doesn't seem to be *completely* out of > > scope. > > > > Is NumberUtils a possible home for this? > > > > On a separate, but related note, I honestly think this sort of math > > actually deserves a full blown java Number implementation (similar to > > BigFraction and Complex classes in commons- numbers). Possibly called > > BigMeasurement? Which can interact with other Number implementations as > > well as other BigMeasurements and retain/report the correct uncertainty > and > > precision throughout the computation. I haven't ironed that out - but a > > necessary intermediate step is just being able to get the sigfig count. > > > > Dan > > >
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
Hm, I too, would expect Thing1Case to mean one thing and one thing only... hence this specification exercise 😉 Gary On Wed, Aug 9, 2023, 9:52 PM Daniel Watson wrote: > I would think it's possible to hide that "configuration" from the user such > that the implementation can only be reconfigured via extension. But I'm not > in love with the configurable base class either way. It was convenient to > have the common functionality in one place, but it's not a big deal to > handle that differently. > > The tradeoff in having the Cases be pure functions is that it makes it more > difficult for a user to extend them with additional functionality. And to > me the need for extension is apparent even when just looking at the 4 basic > cases. Two of them are character delimited, and 2 of them are uppercase > delimited. There's two bits of shared functionality just in the 4 most > basic cases. > > Back to the exception topic, I don't think the tokens "my" "component" and > "1" can be formatted in PascalCase in a way that they could be parsed back > out into 3 tokens. So the question is less about whether it's possible to > format them and more about whether the API should format output that cannot > be parsed back into the same input. I think it makes sense to enforce that > consistency, or at the very least allow the user to enable it? > > > > > On Wed, Aug 9, 2023, 9:14 PM Elliotte Rusty Harold > wrote: > > > On Wed, Aug 9, 2023 at 11:36 PM Daniel Watson > > wrote: > > > > > > Meant to add... > > > > > > The reason I would favor exceptions is that the underlying > implementation > > > can be easily customized. If the user needs to allow non alphanumeric > > > characters there is a boolean flag in the underlying abstract class > > > (AbstractConfigurableCase) that will simply turn that validation off. > > > > This is another point, but customizability is a bug, not a feature. I > > don't want to guess what the method might be doing based on what flag > > was set where. I want camel case to mean one thing and one thing only. > > Ditto snake case, pascal case, and any other formats. Possibly there's > > a reason to add additional subclasses, but the > > CamelCase/SnakeCase/KebabCase classes should not emit different > > strings depending on how they're configured. The public API should be > > a pure function, not an object. > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
If no instance of Thing1Case can be reconfigured, then that holds true, right? The fact that it extends something like DelimitedCase doesn't break the spec I wouldn't think? On Fri, Aug 11, 2023, 11:23 AM Gary Gregory wrote: > Hm, I too, would expect Thing1Case to mean one thing and one thing only... > hence this specification exercise 😉 > > Gary > > On Wed, Aug 9, 2023, 9:52 PM Daniel Watson wrote: > > > I would think it's possible to hide that "configuration" from the user > such > > that the implementation can only be reconfigured via extension. But I'm > not > > in love with the configurable base class either way. It was convenient to > > have the common functionality in one place, but it's not a big deal to > > handle that differently. > > > > The tradeoff in having the Cases be pure functions is that it makes it > more > > difficult for a user to extend them with additional functionality. And to > > me the need for extension is apparent even when just looking at the 4 > basic > > cases. Two of them are character delimited, and 2 of them are uppercase > > delimited. There's two bits of shared functionality just in the 4 most > > basic cases. > > > > Back to the exception topic, I don't think the tokens "my" "component" > and > > "1" can be formatted in PascalCase in a way that they could be parsed > back > > out into 3 tokens. So the question is less about whether it's possible to > > format them and more about whether the API should format output that > cannot > > be parsed back into the same input. I think it makes sense to enforce > that > > consistency, or at the very least allow the user to enable it? > > > > > > > > > > On Wed, Aug 9, 2023, 9:14 PM Elliotte Rusty Harold > > wrote: > > > > > On Wed, Aug 9, 2023 at 11:36 PM Daniel Watson > > > wrote: > > > > > > > > Meant to add... > > > > > > > > The reason I would favor exceptions is that the underlying > > implementation > > > > can be easily customized. If the user needs to allow non alphanumeric > > > > characters there is a boolean flag in the underlying abstract class > > > > (AbstractConfigurableCase) that will simply turn that validation off. > > > > > > This is another point, but customizability is a bug, not a feature. I > > > don't want to guess what the method might be doing based on what flag > > > was set where. I want camel case to mean one thing and one thing only. > > > Ditto snake case, pascal case, and any other formats. Possibly there's > > > a reason to add additional subclasses, but the > > > CamelCase/SnakeCase/KebabCase classes should not emit different > > > strings depending on how they're configured. The public API should be > > > a pure function, not an object. > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
Apache Commons CLI Issue CLI-317
In the DefaultParser class, we are using handleOption method which is defined
as following
privatevoidhandleOption(Optionoption)throwsParseException{
// check the previous option before handling the next one
checkRequiredArgs();
option=(Option)option.clone();
updateRequiredOptions(option);
cmd.addOption(option);
if(option.hasArg()){
currentOption=option;
}else{
currentOption=null;
}
}
option.hasArg() returns true only when argCount is greater than 0 or is
UNLIMITED_VALUES.
But, if our option is built with optionalArg(true), then argCount seems
UNINITIALIZED.
So, if our option is built with optionalArg(true), handleOption(option) sets
currentOption to null which we aren't handling at DefaultParser class LIne 484
