|
I have this actuarial software project in which I have to code some crazy looking actuarial formulas and frankly I have no idea how I can do that?!
Any suggestions appreciated!
Best regards,
k3n3dy
|
|
|
|
|
k3n3dy wrote: Any suggestions appreciated!
Any suggestions? Even the anatomically improbable ones?
I've developed actuarial software in the past - you really need to work with an actuary on this. More importantly though, you need to realise that this is the coding horrors forum - where ungodly code is held up to the sunlight of derision where it bursts into flames. Tell you what, when you've finished your code hold it up for us to have a deride.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: ungodly code is held up to the sunlight of derision where it bursts into flames
PMFSL... that's all kinds of funny...
-------------------------------------------
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Just bugger off and leave me alone!!
|
|
|
|
|
try breaking it into many subprograms.
wont make u lost
-
|
|
|
|
|
jglim1994 wrote: breaking it into many subprograms
Divide and Rule?
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
sort of- at least you dont get lost in a huge pile of code
-
|
|
|
|
|
Sounds like you are on your way to creating a coding horror of your own!!
-------------------------------------------
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Just bugger off and leave me alone!!
|
|
|
|
|
Use the fast C++ in a dll and watch out for precision details. And better disable optimization until you proof that there isnt going something wrong. Use 64bit values int64 and double. Check that the values dont go near 0 or get really big, because it harms precision. First multiply than divide.
Greetings from Germany
|
|
|
|
|
You forgot to tell him to stiffen his sinews and gird his loins. I know that you would expect him to be using the Manly macros, but I suspect that he's actually using the Wimpy ones. But good catch on the first multiply then divide. It's a mistake that people often make.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: tell him to stiffen his sinews and gird his loins.
Because:
"Its fun to charter an accountant, and sail the wide accountan-see!
Its all tax deductible, we're fairly incorruptible
and sailing on the wide accountan-see!"
Please excuse these attack by our introductory film
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all. Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
KarstenK wrote: First multiply than divide
That happens all too often nowadays. People should work harder at fulfilling their commitment.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Phil J Pearson wrote: KarstenK wrote:
First multiply than divide
That happens all too often nowadays. People should work harder at fulfilling their commitment.
Or require a licence prior to multiplication
|
|
|
|
|
Just Copy&Paste them from Excel into VisualStudio and assign the result to a variable.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all. Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
This isn't really a place to ask questions. Its for posting some of the most horrific coding solutions you may have come across.
My current favourite word is: PIE!
Good ol' pie, it's been a while.
|
|
|
|
|
Pie is good. I like pie.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I agree with Pete, I like Pie too. Preferrably Apple.
|
|
|
|
|
These two queries return the same result set(different results as different fields).
A colleague wrote the first query and I wrote the second.
Now I think the first one looks just plain ugly, however the execution plan is not too dissimilar to the second query, which I wrote.
Is there any rationality to my response of Urghhhh?
My colleague's version:
select
sat.salesnumber,
pjq.pickjobnumber
from
(select salesnumber, rownumber, invoiceaccount
from salestable
where dataset = 'wtl'
and ltrim(salesnumber) = '331299') as sat
join
(select * from
pickjobtrans) as pjt
on sat.rownumber = pjt.picksalesrecid
join
(select * from
pickjobqueue) as pjq
on pjt.pickjobnumber = pjq.pickjobnumber
group by sat.salesnumber, pjq.pickjobnumber
</code>
My version:
select distinct pjq.accountnumber,pjq.status
from pickjobqueue pjq
right join pickjobtrans pjt
on pjq.pickjobnumber = pjt.pickjobnumber
right join salestable sal
on pjt.picksalesrecid = sal.rownumber
where ltrim(sal.salesnumber) = '331299'
</code>
You always pass failure on the way to success.
|
|
|
|
|
The one that runs faster
|
|
|
|
|
I think having a column called salesnumber which is actually a char datatype is a bit of a db design coding horror too
|
|
|
|
|
Yes - it's a Mircosoft XAL database.
It would make more sense space-wise as well as a varchar, in this case, will take more space than an int type which only takes 4 bytes.
Microsoft bought the database from Navision who bought it from Daamgard before it was a SQL database.
Let that be a warning to database design - get it wrong at the beginning and you can be left with problems for the life of the product.
You always pass failure on the way to success.
|
|
|
|
|
I am not a fan of SELECT *, It returns too much data, taking up resources along the way. That being said, my only other complaint is the lack of formatting, but that is just code style. I find the extra formatting makes it easier to find the part I want to work on.
SELECT DISTINCT pjq.accountnumber,
pjq.status
FROM pickjobqueue pjq
RIGHT JOIN pickjobtrans pjt
ON (pjq.pickjobnumber = pjt.pickjobnumber)
RIGHT JOIN salestable sal
ON (pjt.picksalesrecid = sal.rownumber)
WHERE LTRIM(sal.salesnumber) = '331299'
Hogan
|
|
|
|
|
I take your point on formatting.
snorkie wrote: I am not a fan of SELECT *, It returns too much data, taking up resources along the way
I am in the same camp as you here, however when I looked at the execution plan both queries have very similar execution plans.
In the end neither was faster.
My position is more that it just looks lazy using those select* statements.
I also find a beauty in being able to write code that is short and concise.
Maybe I am being pedantic and need to let go...
-- modified at 15:28 Tuesday 6th November, 2007
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: I am in the same camp as you here, however when I looked at the execution plan both queries have very similar execution plans.
In the end neither was faster.
To a large extent, the execution plan is immaterial here. What matters more is the amount of data that is returned over the network. If you only need one column, why put more load on what may already be a busy network by returning 20?
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Select *....just say no. It is a lazy approach and as Pete points out you can end up creating a lot of network traffic for no benefit.
|
|
|
|
|
not to mention the possibility of some adding a big field to the end of the table (blob for instance) and your code suddenly grinding to a halt.
I won't use select * even if i want every field as you have no idea what changes may come later
Russ
|
|
|
|