Never pile things together if you intend to treat them differently.
Let's take a simplified example:
List<object> myList = new List<object>()
Putting items in an object list should only be done if you intend to treat this list's items as objects, not as some more specific derived type.
My issue is I need to do various things with each of these elements.
This is a problem of not "getting" OOP. (Don't worry, it's been around for 50 years and most developers don't really get it.)
Can you think of a single word that encompasses all those various things? If you can, make your classes implement an interface that has a method whose name ...
Basically, what you describe here is implementation inheritance (as opposed to interface inheritance). This is different from the "is-a" relationship which presupposes that client code is going to use the derived class polymorphically through a variable that has the type of the base class (i.e., beyond construction, clients will exclusively use the methods ...
There are no absolutes in software design. Some might say that the base class should be Calculator with two children, SimpleCalculator and ScientificCalculator. But that strictly depends on how you want to apportion the methods and properties between the classes.
Should I further break the ScientificCalculator into TrigonometricCalculator, LogarithmicCalculator, etc.?
That's not meaningfully answerable without being explicitly defined by the actual software spec. The exact definition of each type of calculator is not a universal truth; it's a matter of convention and naming - for which you need to have a clear spec.
First, there's nothing wrong with extending a class by another class (inheritance) without overriding its existing members.
Second, doing this (extending but not overriding) doesn't preclude polymorphism. A base class reference could refer to either of the two classes in your example, thus, polymorphism.
Should I further break the ...