Skip to main content
P
pgarbuz1-Visitor
1-Visitor
August 23, 2018
Question

lookup function and the epitome of stupidity at PTC

  • August 23, 2018
  • 1 reply
  • 1720 views

a:=[10nm, 20nm, 50nm, 100nm]

b:=[20%, 15%, 10%, 5%]

 

lookup(10nm,a,b,"eq")=[20% 15% 10% 5%]

 

The problem is that equal (default), range and the rest of the modifiers take tolerance into consideration. Does anyone at PTC even use their own software? How can such an obvious bug, that would take 5 minutes to fix, still exist? How can you have a culture so toxic that it is easier to spend hours writing articles on getting around this bug, than fixing it.

 

Just add another modifier and set the tolerance value in the search to 0. This is incredibly frustrating to see such stupid bugs still around. I guess I may need to get better at yoga, so maybe I can see it as a feature from PTC's point of view. 

 

 

Mathcad... The tool where you spend 80% of your time tracking down and working around bugs that would have taken developers 5 minutes to fix (fuming angry face)

1 reply

W
Werner_E25-Diamond I
25-Diamond I
August 23, 2018
@pgarbuz wrote:

a:=[10nm, 20nm, 50nm, 100nm]

b:=[20%, 15%, 10%, 5%]

 

lookup(10nm,a,b,"eq")=[20% 15% 10% 5%]

 

The problem is that equal (default), range and the rest of the modifiers take tolerance into consideration. Does anyone at PTC even use their own software? How can such an obvious bug, that would take 5 minutes to fix, still exist? How can you have a culture so toxic that it is easier to spend hours writing articles on getting around this bug, than fixing it.

 

Just add another modifier and set the tolerance value in the search to 0. This is incredibly frustrating to see such stupid bugs still around. I guess I may need to get better at yoga, so maybe I can see it as a feature from PTC's point of view. 

 

 

Mathcad... The tool where you spend 80% of your time tracking down and working around bugs that would have taken developers 5 minutes to fix (fuming angry face)

This bug/undesirable behaviour was mentioned here in the forum already many times and, no, I don't think anybody at PTC uses this software professionally.

The problem in your case, as you may already know, are the units. All quantities are stored in standard units and your values in nm are stored as very small numbers with unit meter. Those numbers are below the tolerance and so this undesirable effect show up.

Setting the tolerance to 0 won't be a good idea, either, unless we are dealing with a symbolic engine which stores every number only using integers with arbitrary length (limited by memory only).

Mathcads numerics uses (as most other number crunchers, too) the IEEE format to store their numbers. So every stored number is inaccurate and setting a tolerance of zero might show effects as undesirable than the one you describe.

I guess its not that easy to fix that. You might think of a tolerance dependent on the values in the vector. This would probably work for most cases this function is used in daily work, but what should the tolerance be if you have a vector with some values in nm and some in Mm? tolerance dependable on the smallest value in the vector also might give problems as now the tolerance might be to low for the larger values in the vector which are not found because of numerical inaccuracies.

Dealing with inaccurate numbers is not that easy but I fully agree the while Lookup, Match, etc. probably can't be implemented in a perfect way, they sure could be implemented much better than what we have now.

    P
    pgarbuz1-VisitorAuthor
    1-Visitor
    August 23, 2018

    In that case the tolerance should be off the input not off the data. Now that is that 30 second fix instead of a 5 minute fix... 

     

     

    @Werner_E wrote:
    @pgarbuz wrote:

    a:=[10nm, 20nm, 50nm, 100nm]

    b:=[20%, 15%, 10%, 5%]

     

    lookup(10nm,a,b,"eq")=[20% 15% 10% 5%]

     

    The problem is that equal (default), range and the rest of the modifiers take tolerance into consideration. Does anyone at PTC even use their own software? How can such an obvious bug, that would take 5 minutes to fix, still exist? How can you have a culture so toxic that it is easier to spend hours writing articles on getting around this bug, than fixing it.

     

    Just add another modifier and set the tolerance value in the search to 0. This is incredibly frustrating to see such stupid bugs still around. I guess I may need to get better at yoga, so maybe I can see it as a feature from PTC's point of view. 

     

     

    Mathcad... The tool where you spend 80% of your time tracking down and working around bugs that would have taken developers 5 minutes to fix (fuming angry face)

    This bug/undesirable behaviour was mentioned here in the forum already many times and, no, I don't think anybody at PTC uses this software professionally.

    The problem in your case, as you may already know, are the units. All quantities are stored in standard units and your values in nm are stored as very small numbers with unit meter. Those numbers are below the tolerance and so this undesirable effect show up.

    Setting the tolerance to 0 won't be a good idea, either, unless we are dealing with a symbolic engine which stores every number only using integers with arbitrary length (limited by memory only).

    Mathcads numerics uses (as most other number crunchers, too) the IEEE format to store their numbers. So every stored number is inaccurate and setting a tolerance of zero might show effects as undesirable than the one you describe.

    I guess its not that easy to fix that. You might think of a tolerance dependent on the values in the vector. This would probably work for most cases this function is used in daily work, but what should the tolerance be if you have a vector with some values in nm and some in Mm? tolerance dependable on the smallest value in the vector also might give problems as now the tolerance might be to low for the larger values in the vector which are not found because of numerical inaccuracies.

    Dealing with inaccurate numbers is not that easy but I fully agree the while Lookup, Match, etc. probably can't be implemented in a perfect way, they sure could be implemented much better than what we have now.

     

      Terms & ConditionsAccessibility statement