Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#530 closed proposed feature (invalid)

wrapper/alias for "dim( std(i) )"

Reported by: kroeker@… Owned by: somebody
Priority: minor Milestone:
Component: dontKnow Version: spielwiese
Keywords: dimIdeal wrapper for dim s Cc:

Description

I would like to see somewhere at a prominent place (in kernel or in general.lib) a wrapper/ alias for dim( std(i) ) , like the following snippet:

proc dimIdeal(ideal i)
{
  // check here if active ring type is supported

  def istd = std(i);
  return dim( istd );
}

since this is in many cases what is wanted.

I use this wrapper in our code to prevent accident calls to dim(i) where i is not a standard basis, since in our algorithm this is not intended and just wrong. Although dim compains softly when passing an ideal which is not represented as a standard basis, I find the upper approach superiour.

Comments?

Change History (6)

comment:1 Changed 10 years ago by ren

What would dimIdeal do if the input ideal is not a standard basis? Throw an error or calculate a standard basis from the input ideal?

comment:2 in reply to:  1 Changed 10 years ago by kroeker@…

Replying to ren:

What would dimIdeal do if the input ideal is not a standard basis? Throw an error or calculate a standard basis from the input ideal?

Good point. I do not have strong arguments in favour of one approach, therefore what is about to introduce 2 aliases?:

-bareDimIdeal(): throws an exception if the parameter is not a standard basis and -dimIdeal() : calculates a standard basis internally if needed

The namings are not perfect yet; therefore if you have a better suggestion, please tell.

Of course it would be possible to pass an optional parameter, but then I fear

  1. people will start to discuss what is the default
  2. if in future the default setting will be changed, it could hurt.

comment:3 Changed 10 years ago by ren

I don't know whether introducing new functions is the right way to go. In this case, the root of the problem seems to be that the warning is so easily overseen, so how about we just make it bigger? There is no reason why that warning should ever show up in proper code anyways, in my opinion. If you pluck in a standard basis into dim() without Singular knowing that it is a standard basis then:

a) you know for sure it is a standard basis, in which case you should set the "isSB" attribute to 1. That will also avoid redundant computations should you try to compute the standard basis of I.

b) you know for sure it is not a standard basis, but you are absolutely sure that you want to pluck it into dim() because you know what you are doing. Then you should be capable avoiding the warning by wrongly setting "isSB" temporarily without breaking your code.

comment:4 Changed 10 years ago by kroeker@…

Unfortunately a warning does not help in situations where corrrect behaviour is critical and an issue may be overseen by the authors and by test cases.

A conservative approach is that errors should always hurt. Yes, it's an ideological thing, but I can tell you from my experience as a programmer that it works and the opposite does not. If you don't trust me, ask other experienced programmers you trust. If there will be no punishment for bank robbers there is not much motivation for them to change their behaviour( fix the code )

comment:5 Changed 10 years ago by hannes

Resolution: invalid
Status: newclosed

I can think of at least 5 different versions of behavior, and ALL of them have their use at the aprociate places:

  • d=dim(I); gives a warning as a hint
  • I=groebner(I);d=dim(I); the "safe" variant
  • if (attrib(I,"isSB")!=1) { ERROR("GB required");} d=dim(I); the kindergarden variant
  • attrib(I,"isSB",1);d=dim(I); for people who know for sure that I is a GB
  • if (attrib(I,"isSB")!=1) { I=groebner(I);} d=dim(I); the "on demand" method

And all of them are one-liners, no need to create special routines for that.

comment:6 in reply to:  5 Changed 10 years ago by kroeker@…

Replying to hannes:

I can think of at least 5 different versions of behavior, and ALL of them have their use at the And all of them are one-liners, no need to create special routines for that.

Keep in mind that these one-liners come with a price: since it's in fact duplicate code (if used at more than one place) this may contribute to the maintenance and refactoring nightmare.

<Question>what is the price for my approach? anyone?</Question>

Another issue is, that the assumption, all authors will check the isSB property (if necessary) just before the dim() call like

if (attrib(I,"isSB")!=1) { I=groebner(I);} d=dim(I);

is optimistic: "I computed the standard basis few lines before, why should I check for this again?" Then, the code is modified over time, the parameter for dim() is by accident no longer SB => wrong result.

Note: See TracTickets for help on using tickets.