Refactor number types

Here's a discussion on the refactor of the number types. We had it originally on Hadrien's repo, but I thought it might now be a good idea move it over here. This way, we won't lose track of it in the future.

Here's my summary of the most important points made.

Pol Welter wrote:

Apart from the new CNumber we still have HNumber. The latter is also responsible for the units, so that currently each CNumber effectively stores its unit twice. We had this discussion already, and concluded that for the moment, this was acceptable, but needs to be tackled later. How shall we deal with it in precisely?

I suggest the following:

Remove all the unit related stuff from HNumber, so that it really only represents a real number. Then CNumber is a complex number (still without unit) made up of two HNumbers. Finally, we implement the unit stuff in a new type Quantity, which represents - you guessed it - a physical quantity with its dimension and unit. It is this class that is used by the evaluator.

Also please come up with a better name than 'Quantity'.

Felix Krull wrote:

Without dwelling on this subject too much right now, I think that if we refactor the number stuff, it'd be worthwhile to pull in another abstraction layer so that the evaluator can potentially handle values that aren't actually numbers. I was particularly thinking of https://bitbucket.org/heldercorreia/speedcrunch/issues/508/ascii-value-and-conversions, which'd require the evaluator to parse and handle strings. Without making any arguments on whether supporting ASCII conversion is a good idea (I mean, I'd use it, but it's a bit out of place for a calculator), I'm thinking of making the evaluator handle a Value class roughly like this:

class Value {
  enum Type {
    Quantity,
    // This would just be a Quantity and a format identifier so that stuff could be moved out of the number classes
    FormattedQuantity,
    // other hypothetical things like strings
  };
  union {
    ...
  }

  // For anything that's strictly a number, would return the value for the purposes of arithmetic. For
  // anything else, would return NaN.
  Quantity toQuantity();
  // Format for display purposes.
  QString toString();

  // etc.
};

The idea here being that the evaluator could at least parse and pass around non-number values. All arithmetic and most built-in functions would still be limited to working with numbers, but functions could take non-number arguments and return non-number values. Even if we don't define any non-number value types, I think this would be a good abstraction to have.

Hadrien Thevenau wrote:

One idea: why should the different types be exclusive (like in a union) ? A single "thing" can have several types of value. For example, 1.0 can have both the 1.0 value and "1.0" value. Additionally, a variable has both an l-value (the place in memory in which information is stored) and a r-value (the actual value).

It would also allows to simplify the current parser with units. In the current design, there is a post-processing step after the lexing and before the parsing to process the unit conversion operator in order to feed it the unit display string. Allowing a value to have both a string and a number value would solve this problem easily: the number value would be used for the numeric and the display value for the display.

Felix Krull wrote:

So associating several representations with a single value? So the unit conversion operator would parse its right-hand argument into a value that contains both the actual string that was entered -- for display purposes -- and the associated numerical value for math purposes? That seems like a sensible solution for that situation, but I'm not sure that needs to be generalised into having any arbitrary number of representations for each value or something. I'm still in favour of just a QVariant-style smart union. I don't think there's a wide variety of situations where the representation of a number is not just that number, outside of hex() and friends and the unit conversion operator.

The discussion then veered off topic, and we discussed a refactor of the parser instead. Will open another issue on that matter.

Comments (25)