Can we please get Min and Max functions

[Ex Machina]

So:

If you add two numbers and then half the sum, you get the average value. If you subtract them and half the absolute of the result, you get the distance of the either of them from the average. It follows then that:

MAX=1/2*(X+Y+ABS(X-Y))
MIN=1/2*(X+Y-ABS(X-Y))

The ABS() function is available in the Equation Editor.

It only work for two factors though. I didn't think if it would scale to more. Maybe if you apply it iteratively, with successive parentheses, it would scale to more numbers, but I'm too tired to sit down and work this out.

 

[Stuart]

So:

If you add two numbers and then half the sum, you get the average value. If you subtract them and half the absolute of the sum, you get the distance of the either of them from the average. It follows then that:

MAX=1/2*(X+Y+ABS(X-Y))
MIN=1/2*(X+Y-ABS(X-Y))

The ABS() function is available in the Equation Editor.

It only work for two factors though. I didn't think if it would scale to more. Maybe if you apply it iteratively, with successive parentheses, it would scale to more numbers, but I'm too tired to sit down and work this out.

Don't take this the wrong way, but I wasn't asking for a solution. I know there are convoluted ways to get the same result. For my current needs, I've decided to use the option of manually picking the correct value over using multiple sketches and extrusions or very unreadable equations. In my case I added a note to the value I picked saying it needed to be the max of two values.

I want the purpose of my equations to make sense just be reading them. I don't want to scrath my head a year from now wondering why I had an equation like 1/2*(X+Y+ABS(X-Y)).

My post was why such a simple function, just like ABS() is't already available. There's hardly a project I do where I wouldn't use it.

 

[Ex Machina]

Sure, that makes sense. I was just trying to give you a solution to get by for now. Actually, another way to get by until something like this is implemented is using an Excel spreadsheet to drive parameters. Maybe that functionality is the reason min and max have not been implemented yet.

P.S. If you look at the available functions in the Equation Editor, none of them is something that would need a while or a for to compute. Furthermore, all of them only take a single argument as input. Where as MIN and MAX would need two or more by definition. Maybe that's the reason it was never implemented.

 

[DavidJ]

Can you find out why my long standing request has never been implemented?

Stuart - I can find no entry for it in the system that I have access to. That could mean any of
* It wasn't recorded
* It was lost in change of systems between Geomagic and Alibre, LLC.
* It was recorded somewhere that I don't have access to.

I'm adding it now so it doesn't get lost.

I can see potential issues if such a function is used with mixed types (length, count, angle, scale) - simplest might be to restrict function to only be legal if all inputs are the same type. Do you see use cases where working with mixed types would be needed?

 

[Stuart]

Stuart - I can find no entry for it in the system that I have access to. That could mean any of
* It wasn't recorded
* It was lost in change of systems between Geomagic and Alibre, LLC.
* It was recorded somewhere that I don't have access to.

I'm adding it now so it doesn't get lost.

I can see potential issues if such a function is used with mixed types (length, count, angle, scale) - simplest might be to restrict function to only be legal if all inputs are the same type. Do you see use cases where working with mixed types would be needed?

Thanks.

The types should always be the same.

Please also add an entry that a distance or angle */ by a count or scale should always result in a distance or angle. If needed, parenthesis could be required to enforce this rule (operator precedence). I regularly have to make additional parameters because it doesn't understand/accept this math inside an equation.

 

[DavidJ]

Stuart that sounds like an unrelated request.

I don't see any problem currently




Can you expand on what you think is wrong?

 

[DavidJ]

Ah perhaps you are actually referring to manually typing the count or scale values directly ? The issue there is that ALL numeric input is assumed to be of the type defined for the field in use - so if a distance field is being worked on and you type in *1.5 it assumes * 1.5mm (say) which will typically result in a mismatch of dimensionality.

Whilst you can force dimensionality of Distance or Angle by typing in a unit, you can't remove the set dimensionality when entering a numeric value.

 

[Stuart]

Ah perhaps you are actually referring to manually typing the count or scale values directly ? The issue there is that ALL numeric input is assumed to be of the type defined for the field in use - so if a distance field is being worked on and you type in *1.5 it assumes * 1.5mm (say) which will typically result in a mismatch of dimensionality.

Whilst you can force dimensionality of Distance or Angle by typing in a unit, you can't remove the set dimensionality when entering a numeric value.

The constants not having "units" is definitely a problem (please make an entry for the ability to add a "unit"), but I think I've had this with parameters too. I'll see if I can dig up an example this weekend. It's usually when the formula has multiple components in it.

I just thought of something... It might be that (distance / distance) or (angle / angle) should be a scale so that (distance * (distance / distance)) == distance.

Sorry for the tangent, but since it was equation editor syntax I thought I'd add it.

 

[DavidJ]

Dimensionality is EXTREMELY STRICTLY enforced in EE - many users confuse dimensionality with dimensions.

If you want a 'constant with units' then surely it is a distance or an angle, just with a fixed value.

I am still not clear quite what you are getting at. And if you have an enhancement request - there is a category for that on the support form. Happy to discuss pros and cons here, but don't want people to get the idea that a discussion here equates to any formal request.

 

[Stuart]

A constant is just a number, unitless, which is why I put "units" in quotes. There needs to be a way to say a constant value is just a number. Otherwise it seems to be interpreted as something else. I'm not sure, because the error is simply not valid.

Here's acouple of examples of failures. I'll look for more that I've encountered

You can't specify a constant value angle in degrees inside trig functions using "deg" or the degree symbol. You have to create a separate angle parameter. However, you can use the "deg" units elsewhere. Without being able to specify degrees, it assumes radians.


(6mm/ 2mm) is a unitless number, so angle A2 / a number is still an angle, but it won't accept it.

 

[DavidJ]

So is it the fact that EE can't cope with entries of differing value type in a single cell ? Instead you have to do things in stages. I know there is already an enhancement request existing about that (as I created it) - To me it does seem that the Type/Dimensionality checking is a bit too restrictive, maybe that was done for simplicity or performance - I just don't know.

I'd argue that a constant is simply a value that doesn't change (regardless of units or dimensionality/type).

 

[bolsover]

Stuart - I can find no entry for it in the system that I have access to. That could mean any of
* It wasn't recorded
* It was lost in change of systems between Geomagic and Alibre, LLC.
* It was recorded somewhere that I don't have access to.

I'm adding it now so it doesn't get lost.

@DavidJ
This highlights one of the reasons why I have been calling for bugs, work arounds and enhancement requests to be made public - or at least available to forum members.
It is wonderful how an open list concentrates developers minds!

Great example of how this should be done here..

Jetbrains

David

 

[Stuart]

This highlights one of the reasons why I have been calling for bugs, work arounds and enhancement requests to be made public - or at least available to forum members.
It is wonderful how an open list concentrates developers minds!

+1000! I would love to know the status of bugs and feature requests I've submitted to support.

 

[Stuart]

So is it the fact that EE can't cope with entries of differing value type in a single cell ? Instead you have to do things in stages. I know there is already an enhancement request existing about that (as I created it) - To me it does seem that the Type/Dimensionality checking is a bit too restrictive, maybe that was done for simplicity or performance - I just don't know.

I'd argue that a constant is simply a value that doesn't change (regardless of units or dimensionality/type).

In this case I'm referring to literal constants like 2.5, rather than constants in the EE like Pi.

The problem is that the EE parsing / processing is weak / broken in some cases and should be fixed.

I bothers me that Tech Support is so focused on work-arounds. I shouldn't have to preface an issue report with "I'm reporting a bug. I don't need a work-around." It makes me wonder if the bug will ever be fixed as long as there's some work-around, regardless of the work-around complexity.

 

[DavidJ]

On constants - I think you just agreed with me.

I asked for a specific clarification of the problem to check my own understanding - instead of 'yes', 'no', or 'I'm not really sure what you are asking' - you say "The problem is that the EE parsing / processing is weak / broken in some cases and should be fixed." I was trying to check if what I mentioned in post #27 about directly typed inputs is indeed the explanation of your annoyance with EE, or if I've missed some additional point/subtlety.

My own approach for support - and sorry if you don't approve, is

1. Try to clarify / understand exactly what the issue is (so if it is a bug, development will have a clear target, not some vague complaint).
2. If the issue could be a bug or could be intended behaviour (even if the reporter doesn't like that) I try to find out which it is (can't always get an answer).
3. If a confirmed or possible bug, or an enhancement request, enter it into the development tracking system (with sample files etc.). Let the customer know I've done that.
4. Try to offer a way for the user to complete their immediate task, yes a workaround if there was a bug or lack of functionality involved.

Support can't fix the software - that isn't our task or skill-set. Most support tickets arise because a user can't achieve something, it's our job to try to help them make progress.

Most 'bug' reports actually turn out to be not bugs at all - but that's another story.

So I make no apology for being 'focussed on workarounds' or more widely helping users to make best use of our software. I can't fix the software, nor do I assign priority on the items to be fixed. Where there is a bug (or possible bug), I can try to gain as much clarity on the issue as possible, so that any future fix delivers what the user wanted, and not something else.

There are 'grey areas' where some behaviour may be a 'bug', but there could have been a valid decision taken that it should be that way (maybe for performance reasons, or to avoid additional complexity).

Getting the totally clear definition of what the user sees as a 'bug' or 'wrong behaviour' is probably the most difficult part of my role. The same words can mean a range of things to each reader.

 

[Stuart]

I showed you screenshots where the EE fails, giving a invalid data message on valid input and your response is to ask if I was "annoyed" with having to use the workaround of two stages.

I was simply showing a bug. I've written 3 separate equation parsers/evaluation libraries. I know what a bug looks like. This is either broken, or more likely, not implemented fully. Either way, it's still a bug even if it's resolved won't fix. The "invalid" input works in the two stage solution, so the EE can handle the input, it just can't handle it within a single equation in parnethesis. That's clearly a weakness at best.

I know you said this wasn't the right area, but your first post was to offer a step "4" work-around to a post asking for a feature.

 

[DavidJ]

Stuart, I am only trying to verify whether what you are complaining about is same or slightly different than something I know has been logged.

 

[DavidJ]

Some background; Dimensions are essentially members of the equation editor.

When typing into a dimension field it is helpful in most cases that the currently set units are assumed for typed in values in distances and angles. It speeds up entries considerably. Units can be overridden if needed, by explicitly typing in the desired alternate unit.

That behaviour in the cases discussed above creates problems. Now I don't have Stuart's knowledge of equation parsers, so I all I can do is try to clarify/confirm the problem behaviour is understood and recorded - in this case, does the assumption of the selected unit fully 'explain' (at least potentially) the reported behaviour? I can pass that on to development.

I don't know if some way to override the usual assumption when typing could help, or if there is some clever way that a parser could ever know when a typed value should be assumed to have units and when not.

Do we remove what is usually a helpful behaviour, to avoid the reported issue? I don't have any simple answer to that.

I've spent more than enough of my own time on this today. Seems I would have been better not posting at all.

 

[Stuart]

Part of the confusion may be the use of the term "units". Units are mm, inches, feet, degrees, radians, etc. The problem is with the interpretation of the TYPE of the constant literal number. The type of a number is determined by the context, i.e. the type of the value it's being operated on. Example: Distance + 3 means 3 is a Distance. the UNITS of 3 can be assumed to be mm or inches, but the TYPE must be a Distance.

Here's another one I just hit.

ANGLE_PARAMETER = (360 deg / COUNT) * (COUNT - 1) was changed to (360 deg / COUNT) * (COUNT - 1 °) <--- note the degree symbol added

In this case, the "1" was assumed to of type ANGLE because the parameter being set is an Angle. Then the degree symbol was assumed for an angle of "1". What should have happened is the "1" should have been treated as a Count type because it's in the context of, and operating on, a Count parameter in "(COUNT - 1)". Once it knows it's a Count type, the units can be assumed, which in this case, is a count, which doesn't have units.

Also, parenthesis (should) force the interpretation of what's inside them. You only coerce / force/ asume the type when parenthesis are omitted. Even then you have rules like operator precedence and left to right processing.

If these standard rules were followed, all TYPES would be strictly enforced, and only UNITS would be assumed to "speed up entries considerably"

 

[Ex Machina]

Part of the confusion may be the use of the term "units". Units are mm, inches, feet, degrees, radians, etc. The problem is with the interpretation of the TYPE of the constant literal number. The type of a number is determined by the context, i.e. the type of the value it's being operated on. Example: Distance + 3 means 3 is a Distance. the UNITS of 3 can be assumed to be mm or inches, but the TYPE must be a Distance.

Here's another one I just hit.

ANGLE_PARAMETER = (360 deg / COUNT) * (COUNT - 1) was changed to (360 deg / COUNT) * (COUNT - 1 °) <--- note the degree symbol added

In this case, the "1" was assumed to of type ANGLE because the parameter being set is an Angle. Then the degree symbol was assumed for an angle of "1". What should have happened is the "1" should have been treated as a Count type because it's in the context of, and operating on, a Count parameter in "(COUNT - 1)". Once it knows it's a Count type, the units can be assumed, which in this case, is a count, which doesn't have units.

Also, parenthesis (should) force the interpretation of what's inside them. You only coerce / force/ asume the type when parenthesis are omitted. Even then you have rules like operator precedence and left to right processing.

If these standard rules were followed, all TYPES would be strictly enforced, and only UNITS would be assumed to "speed up entries considerably"

Yes Stuart, but as I show in one of my videos, even Distance +3 does not work in some CAD systems, namely Onshape, FreeCAD and potentially Solidworks. First two I have checked. You see Mechanical CAD is about making a physical object and it considered a safety measure to need to manage the units in an equation as you would do in a physics calculation or on paper.

What you experienced, count-1 being changed to count-1° is the sole reason that Distance + 3 worked in the first place. Because it was changed to Distance + 3mm.

In any case, this has been debated furiously in another thread and the pattern I see emerging is that people with a Software Development background want it to work more like excel or Python and Mechanical Engineers are happy with the way it works.

In my opinion, with the option to us Excel as an Equation Editor, the built-in equation editor should remain as is.