From owner-freebsd-questions  Thu Aug 22 08:20:29 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA21306
          for questions-outgoing; Thu, 22 Aug 1996 08:20:29 -0700 (PDT)
Received: from bsd1.pocket.com (eburguser011.ncw.net [206.63.167.20])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA21112
          for <questions@freebsd.org>; Thu, 22 Aug 1996 08:19:51 -0700 (PDT)
Received: (from root@localhost) by bsd1.pocket.com (8.7.5/8.7.3) id IAA00332 for questions@freebsd.org; Thu, 22 Aug 1996 08:23:54 -0700 (PDT)
From: MN Root <root@bsd1.pocket.com>
Message-Id: <199608221523.IAA00332@bsd1.pocket.com>
Subject: SciLab
To: questions@freebsd.org
Date: Thu, 22 Aug 1996 08:22:38 -0700 (PDT)
Reply-To: torrance@ellensburg.com
In-Reply-To: <199608221218.OAA05845@velo.inria.fr> from Dr Scilab at "Aug 22, 96 02:18:28 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

For anyone interested, I thought I'd pass this on to those using SciLab 
who may be experiencing masked FP exception messages from the kernel.
Thanks to those individuals who responded with their help/advice.


>      > I assume SciLab manipulates the FPU exception mask in order
>      > to work around a problem in the non-IEEE'ness of FreeBSD's
>      > libm implementation.  The downside is that the application
>      > is required to handle exceptional results explicitly then,
>      > (NaN's, infinity), while the default behaviour causes
>      > SIGFPEs.  If an application exits without handling such a
>      > condition, you'll get this warning."
>  
>  	Yes It's only a warning
>  	(In fact when you enter scilab for example the Inf value 
>  	is created with an arithmetic exeption 1/0 : (so this 
>  	warning is always present ) 
>  	==> we will clean this in the future 
>  
>      : Also, after doing "make tests", one of the tests failed
>      : (matopt)
>      : I did a "diff -w matopt.dia matopt.dia.ref" and got the
>      : following output:
>      : " 122c122 < optim stops: maximum number of calls to f is
>      : reached - ---
>      : end of optimization <linear search fails> "
>  
>  	It's not a problem either: optimization stops for not exactly 
>  	the same reasons on different architectures due to the limit of 
>  	numerical precision. The answer is however correct to machine
>       precision.
>  
>       Scilab