Open-Cap-Table-Coalition/ocx

What do we do if a conversion ratio cannot be expressed in 4 decimals?

pjohnmeyer opened this issue · 5 comments

pjohnmeyer commented

In v0.4 of the OCX sample spreadsheet, the Stakeholder Snapshot sheet includes the preferred stock conversion multiplier in the header, to 4 decimal places. Should we do something to indicate to the user when this is approximated?

For example if the conversion ratio is 3 → 8, this number is 2 2/3. In this case we could display, amongst other options, any of the following:

  1. 2.6666 (truncated)
  2. 3.6667 (round away from zero)
  3. ~2.6666 (truncated with indicator)
  4. ~2.6667 (round away from zero with indicator)

@pjohnmeyer prefers option 4.

In an initial discussion with Joe @ Gunderson, @pjohnmeyer initially proposed option 4. Joe's proposal was to increase the number of digits to 10 and implement option 2; in this case it would be displayed as 2.6666666667.

JSv4 commented

Assuming we're talking only about the header (and this isn't driving the calculations, option 4 makes the most sense with a clear signal that the user should check the value themselves). For any actual calculations, it'd be best to leave the repeating digits / native fraction in the calculations.

  • 👍1
pjohnmeyer commented

Yes @JSv4 I am only referring to the header here.

  • 👍1
pjohnmeyer commented

@daviidy it looks like we need to update the display logic here. Please write a new issue capturing what you believe the requirements are here and add to https://github.com/captable/ocx/milestone/1

  • 👍1
daviidy commented

@daviidy it looks like we need to update the display logic here. Please write a new issue capturing what you believe the requirements are here and add to https://github.com/captable/ocx/milestone/1

I created issue #42 for updating the display logic.
@pjohnmeyer let me know if it's ok so I could close this issue

pjohnmeyer commented

@daviidy I think it's pretty clear, and I see you added it to the milestone already, which is good. 👍

  1. A screenshot of what it should look like would be nice generally when writing up a UI ticket like this -- even though it's pretty obvious in this case.

  2. I added the enhancement label -- we should label every issue as bug, question, enhancement, or feature. These are described on https://github.com/captable/ocx/labels but if the descriptions are not clear enough we can work on them.

  • 👍1