Re: [Ql-Users] ACOS_2

2016-05-31 Thread Mark Martin
On Tue, May 31, 2016 at 3:16 PM, Norman Dunbar 
wrote:

> Hi Colin,
>
> Checking that values are in range in order to call a built in function,
> procedure etc is normal. At least it as been for as long as I've been
> programming - since pre ZX81 days.
>
>
This is definitely a core software engineering process -- alive and well in
today's software dev.  It has the fancy name of "preconditions"/"post
conditions" (often included with "class invariance" when referring to OO
based development).  The core concept is simple:

 - this function (or object method) is meant to work for THIS range of
input values.  If you don't supply a value in THIS range, all bets are
off.  I might give you garbage, or, if I'm more formal, I will throw an
exception or raise an error.
 - this function (or object method) is guaranteed to return a value in THAT
range.

For purer programming, the function SHOULD be idempotent and repeatable.
Sun's Solaris documentation notes that on every function.  But that's
getting into side-effects and monoids and whatnot.

See Modula-2.  It actually has language features to enforce pre-conditions.

Colin, I agree that this violates the principle of least astonishment, but
if it were me, I'd just put the value guard up, drop a quick note why, and
drive on.  I can not tell you how many times I've had to put up similar
guards and notes for similar reasons -- undocumented (or poorly documented)
edge conditions on input values.

Could you just put a CEILING (or FLOOR) around it to tighten the syntax?
___
QL-Users Mailing List


Re: [Ql-Users] ACOS_2

2016-05-31 Thread Norman Dunbar
Found it!

SQL> -- Without brackets. Value for A adjusted.
SQL> select power(1.414214,2) - power(4.242641,2) - power(2.828427,2) / (-2 * 
4.2426
41 * 2.828427) as answer from dual;
 
ANSWER
--
-15.68
 
 
SQL> -- With brackets. Value for A adjusted.
SQL> select (power(1.414214,2) - power(4.242641,2) - power(2.828427,2)) / (-2 * 
4.24
2641 * 2.828427) as answer from dual;
 
ANSWER
--
 1

Cheers,
Norm.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
QL-Users Mailing List


Re: [Ql-Users] ACOS_2

2016-05-31 Thread Norman Dunbar
Hi Colin, 

Checking that values are in range in order to call a built in function,  
procedure etc is normal. At least it as been for as long as I've been 
programming - since pre ZX81 days. 

Even now I still check and this includes when writing code to run on my 
numerous Oracle databases - which today calculated VV to be 1 for the values 
given, with A corrected and parenthesis around the A^2, B^2 and C^2 part. It 
was well off without the parenthesis, but I can't remember the actual value. 
(15e-10 possibly, but don't quote me!)

Defensive Programming is what it used to be called, but in these days of 
"agile" (hack, spit) so - called programming,  it's probably not done any more! 

Og course, one could imagine that ACOS itself would practice such things, and 
it appears that it does, giving you an error when the parameter goes out of 
range.

HTH 

Cheers,
Norm. 


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
QL-Users Mailing List


[Ql-Users] ACOS_2

2016-05-31 Thread Colin McKay
Tim,

A should equal 4.242641. Apologies.

VV is double vee.

 

Marcel,

So when there is any chance that ACOS has to work on any number close to 1,
or -1, a check such as IF VV>1 THEN : VV=1 has to be incorporated on every
occasion?

Takes some of the slickness off the programming.

 

Colin 

 

34 Taylor Avenue

Kilbarchan

Johnstone

Renfrewshire

PA10 2LS

 

Tel/fax  01505 70 4471

 

___
QL-Users Mailing List


Re: [Ql-Users] ACOS

2016-05-31 Thread Wolf

Hi,

probably rounding errors.

a = 1.0009
print a  (prints 1)
print ACOS (a)
gives error in expression.


HTH

Wolfgang
___
QL-Users Mailing List