Project

General

Profile

Design #1681

Should Starting be case-insensitive?

Added by John Abbott almost 2 years ago. Updated 4 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Anna Maria Bigatti
Category:
enhancing/improving
Target version:
CoCoA-5.4.2
Start date:
06 May 2022
Due date:
% Done:

20%

Estimated time:
Spent time:
0.70 h

Description

Currently starting is case-sensitive
e.g. starting("J") and starting("j") give quite different results.

Should the search be case-insensitive?
Or at least should there be an option to say whether to be case-sensitive or not?

History

#1 Updated by Anna Maria Bigatti almost 2 years ago

yes, I think that would be a good idea, case insensitive (ci by default if we allow both).

#2 Updated by John Abbott about 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

A disadvantage of being case insensitive is that it may sometimes produce too much output...
in theory... are there any plausible genuine cases where this could occur?

If we want to offer both possibilities how should they be called?
One silly proposal: starting for case insensitive, and Starting for case sensitive.

The real question is between:
  • one name with an optional parameter
  • two different (but presumably very similar) names

Right now I find the "optional parameter" proposal less appealing... feels like too much hassle for the user.

#3 Updated by John Abbott about 1 year ago

I have just revised the impl in coclib.cpkg5
Right now there is a local variable which says whether to do a case-sensitive comparison or not (but the value of the local variable is currently fixed). I must say that the code has become a bit uglier... it'd almost be neater to make two copies of the code (ouch!)

I'll check in so that we can try it... currently it is fixed to be "not case-sensitive".

#4 Updated by John Abbott 4 months ago

  • Assignee set to Anna Maria Bigatti
  • % Done changed from 10 to 20

There is a small problem with some entries appearing twice:

/**/ S := starting("");
/**/ indent([n in S | "IsLexSeg" isin n.name]);
[
  record[IsExported := true, name := "$monomial_ideals.IsLexSegment"],
  record[IsExported := false, name := "$monomial_ideals.IsLexSegment_Lex"],
  record[IsExported := true, name := "$monomial_ideals.IsLexSegment"]
]

I think the problem may apply to exported names only... not sure though.

#5 Updated by John Abbott 4 months ago

Should we offer a case-insensitive string comparison function?

Also available in: Atom PDF