Best way to store calc result that can be "NA"?

[PeteCresswell]

I was happily coding along, putting some calculation results (rolling
annualized rates of return - too compute-intensive to calculate
on-the-fly - had tb staged beforehand via a batch job) into Double
fields.

Now, the clients have just dropped a litle bomb: they want to see
"(NA)" if the calculation failed due to insufficient input data.

That means our fields can have three kinds of values:

- Null: (something to say we've never even tried to make the calc)

- Decimal: (let's say -99.00 to +99.99 - including zero)

- CalcDidNotWork: Something that says we tried the calc and there was
not enough data
My kneejerk is to change these to text fields, but I wonder if greater
minds than mine have come up with a better approach.

?

[Bob Quintal]

PeteCresswell <x@y.z> wrote in
news:cj******** *************** *********@4ax.c om:

And, while I'm at it...

Is there any downside to storing amounts as percentages
instead of storing them as decimals and changing to percent
for display.

I've always stored as decimal numbers and comverted...but
somebody thinks it would be better to store as percent.....

And someone surely thinks the world is flat.
Since a percentage is by definition the ratio of two numbers, the
"correct" way is to never store the ratio but calculate it when
needed, based on the rationale that somebody will forget to
change the result after changin one of the two numbers.

Now I realize you said that you are precalculating some values,
so that may mitigate the lack of correctness, but I would
hesitate to go further than what is actually necessary in the
pre-calculation, therefore I would convert from a fraction to a
percent at display time, never before.

--
Bob Quintal

PA is y I've altered my email address.

[Bob Quintal]

PeteCresswell <x@y.z> wrote in
news:fq******** *************** *********@4ax.c om:

I was happily coding along, putting some calculation results
(rolling annualized rates of return - too compute-intensive to
calculate on-the-fly - had tb staged beforehand via a batch
job) into Double fields.

Now, the clients have just dropped a litle bomb: they want to
see "(NA)" if the calculation failed due to insufficient input
data.

That means our fields can have three kinds of values:

- Null: (something to say we've never even tried to make the
calc)

- Decimal: (let's say -99.00 to +99.99 - including zero)

- CalcDidNotWork: Something that says we tried the calc and
there was not enough data
My kneejerk is to change these to text fields, but I wonder if
greater minds than mine have come up with a better approach.

?

I handle this sort of situation by including a second field that
returns the value type (calculation status), say an integer type
with 1,2,3 for your 3 kinds.

At display time, use a case structure or nested iif() functions
to display what is needed.
--
Bob Quintal

PA is y I've altered my email address.

[(Pete Cresswell)]

Per Bob Quintal:

but I would
hesitate to go further than what is actually necessary in the
pre-calculation, therefore I would convert from a fraction to a
percent at display time, never before.

That's always been my gut-level feeling - but I never had the words to back it
up...
--
PeteCresswell

[(Pete Cresswell)]

Per Bob Quintal:

I handle this sort of situation by including a second field that
returns the value type (calculation status), say an integer type
with 1,2,3 for your 3 kinds.

At display time, use a case structure or nested iif() functions
to display what is needed.

I think that's where I'm going.

Using wildly out-of-range values called out to me for a short time...but it
seems like I'd be exposing myself to unforseen situations like SUM() and
whatever other calculations might be made - which already nailed me on the input
side before it dawned on me that Lipper indicates a Null return value with
-99.99 and PSN indicates same with a -999.

--
PeteCresswell

[PeteCresswell]

On Tue, 22 Feb 2005 19:29:56 -0500, "(Pete Cresswell)" <[e-mail] d>
wrote:

I handle this sort of situation by including a second field that
returns the value type (calculation status), say an integer type
with 1,2,3 for your 3 kinds.

Just as a point of interest; I thought "Well, this is an
under-the-covers sort of thing, so why not just use a text field and
populate it with a literal value describing the situation...no table
to link to, no translation when somebody wants to see what's
happening..

Turns out that Text fields are a lot more expensive than Longs.... The
DB size lept from 44 megs to a half-gig....

So I'm back to doing exactly what you suggest - with a little system
table "zstblCalcS tat" to document the values, but no RI on the values.

[Bri]

Pete,

It gets even stranger. I'm using Mozilla 1.4.1 and in the Thread Pane
there is only one Re:, but in the Message Pane it shows the three ("Re:
Re: Re: Best...). OK, now I notice that the Subject in this Reply also
only has the one Re: in it. One least thing to check... Yup, the message
source of your message shows the three of them. In my case I would say
that Mozilla figures out that there are redundant ones and filters them
out when viewing the subject (except the Message Pane and the Source).

--
Bri

PeteCresswell wrote:

One more (unrelated) thing:

Is it just me, or are there "Re" literals proliferating in my replies?

My current subject line looks like:

"Re: Re: Re: Best way to store calc result that can be "NA"?"

Some setting in my newsreader (Agent)?

[(Pete Cresswell)]

Per Bri:

In my case I would say
that Mozilla figures out that there are redundant ones and filters them
out when viewing the subject (except the Message Pane and the Source).

It's got tb something with my Agent setup bc the copy I run at home does not do
that - yet the copy I run at a client site does.
--
PeteCresswell