AnsweredAssumed Answered

vrf Strange error message - Vee bug?

Question asked by VRFuser on Mar 24, 2003
Mike:

The "Real" data type has always been a Real64 (double).  VEE 6 added new data types for Real32 (a "float" in "C" land), UInt8 (Unsigned 8bit Integer) and Int16 (Signed 16 bit integer).  Really!

Ken


-----Original Message-----
From: Mike Groves [mailto:mikegroves@pacbell.net]
Sent: Monday, March 24, 2003 11:30 PM
To: VEE vrf
Subject: [vrf] RE: Strange error message - Vee bug?

Kathy,

I think up to Rev 6 there was no REAL64. When you declared something
as REAL, it meant REAL32. Now when you declare something as REAL it
means REAL64. You must specifically declare REAL32 if that's what you
want.

Mike Groves

BTW, what are you doing up so late?? 

-----Original Message-----
From: Kathy Kiessling [mailto:k.kiessling@attbi.com]
Sent: Monday, March 24, 2003 10:07 PM
To: VEE vrf
Subject: [vrf] RE: Strange error message - Vee bug?


It has recently become clear to me that  +0 does not equal -0 in floating
point representation. (IEEE Standard 754 Floating Point Numbers), in either
single or double precision.  Vee handles -0 in Real64 as a +0, but in Real32
they are seperate distinct values.  I would think that VEE would handle
the -0 the same way in either case... so IMHO its a bug.  Up to Rev. 6.0,
there was no Real 32 was there?

-- Kathy Kiessling

----- Original Message -----
From: "Brown, Michael L CAR" <Michael.L.Brown@carrier.utc.com>
To: "VEE vrf" <vrf@it.lists.it.agilent.com>
Sent: Monday, March 24, 2003 3:17 PM
Subject: [vrf] RE: Strange error message - Vee bug?


> Interesting problem, indeed!
>
> I was able to duplicate the error in various guises.  (See attached
> QuadChk3.vee.)  I wrote the values to a binary file and read them back as
> bytes in order to reveal the binary representation.
>
> VEE appears to follow the convention of representing a Real32 positive
zero
> as
> 0 00000000 0000000000000000000000000
> and a Real32 negative zero as
> 1 00000000 0000000000000000000000000
> The Real64 representations are similar, but with 32 more 0's at the end.
>
> The strange error only occurs for Real32 negative zero, even though both
the
> Real32 and Real64 representations have the sign bit set.
>
> Curiously, the function abs(x) does not reset the sign bit to 0, i.e.,
> abs(x) = -0, where x = -0.  Of course, abs(0) = 0.  Also,
> abs( asReal32("0"))  = 0, abs(-asReal32("0"))  = -0,
> abs(-asReal32("-0")) = 0, abs( asReal32("-0")) = -0,
> abs( asReal32(0))    = 0, abs(-asReal32(0))    = -0,
> abs( asReal32(-0))   = 0, abs(-asReal32(-0))   = -0.
>
> I also noticed the following odd arithmetic:
> 0 + (-0) = 0, (-0) + 0 = -0,
> 0 - (-0) = 0, (-0) - 0 = -0.
>
> Is it a bug or a "feature"?
>
> Michael Brown
> Carrier Corporation
>
>
> -----Original Message-----
> From: Kathy Kiessling [mailto:k.kiessling@attbi.com]
> Sent: Monday, March 24, 2003 5:53 AM
> To: VEE vrf
> Subject: [vrf] RE: Strange error message - Vee bug?
>
>
> ah ... cool problem.  I was able to repeat the problem as Barrie and Mike
> did.
>
> First to make a little more sense of the error message -- "In try
(expr)!=0
> the value must equal either all zeroes or non-zeroes. "
>
> I've come across the try .. catch construct in C++ and VB.net, both
> object-oriented approaches.  In general you put a Try statement before a
> code block and if there are any errors/ exceptions in that block, the
catch
> block is supposed to handle them, usually selectively by error type.
> Anything that isn't handled gets passed up the call stack until something
> else there handles it.  If nothing 'catches' and handles the error, it
> crashes the program.
>
> Here they are trying to evalate the expression, and if it's 0, it's false
> and if it's anything but zero it's true.  The first case is the one that
is
> getting caught up.  The triadic returns the 'true' answer to the ?, which
is
> Cdir.  I broke out each line into seperate formula boxes so I could see it
> more clearly and borrowed Mike's many-zero box.  The first case returns
> Cdir, whether Real64 or Real32, and the other all return Int32. All are
> zero.   In my little file I tried a simpler If/Then that produced the same
> error.  Same basic problem - it doesn't recognize the Real32 as a zero.  I
> don't have a clue why.  I tried reading about single and double-precision
> floating point numbers a tthe following web site:
>
> http://research.microsoft.com/~hollasch ... float.html
>
> Eventually I found the part the says single-precision numbers cannot
> represent a zero, but zero is treated as a 'special number'.
> A positive zero is 0 00000000 0000000000000000000000000, but a negative
zero
> is 1 00000000 0000000000000000000000000.  However, this should also be
true
> for double-precision.
>
> A few intestesting obervations:
>
> -- changing (Cdir) to (Cdir-360+360) seems to fix the problem.  (I put
> parenthesis in here for clarification - it doesn't matter in the code).
> -- other object seem to handles this negative zero differently.  I stuck a
> couple at the top of the file.
>         when writing to a container, it treats it like a real zero. -  no
>                 problem
>         when used in a triadic , it works correctly sometimes: (A is
Cdir )
>                 (A==0? A: B) evaluates to A, for Cdir = +0 and Cdir =  -0.
>                 (A!=0? A: B) evalutes to B, for Cdir = +0 and Cdir =  -0
>                 (A? A : B) evaluates to A dir for Cdir = -0 but to B if
Cdir
> =  0.  No error is generated in any of these cases.
>
> -- Kathy Kiessling
>
> ----- Original Message -----
> From: "Mike Groves" <mikegroves@pacbell.net>
> To: "VEE vrf" <vrf@it.lists.it.agilent.com>
> Sent: Sunday, March 23, 2003 4:48 PM
> Subject: [vrf] RE: Strange error message - Vee bug?
>
>
> > Barrie,
> >
> > That's a weird one alright. I played with it for a while and came to
> > the same conclusion that setting a Real32 to -0 does something strange
> > to VEE. I tried to look at the number down to a bunch of places to see
> > if I could spot anything unusual going on. Nothing I could see was
> > different between 0 and -0.
> >
> > The attached file does the same thing as yours, except I don't use a
> > pin to pass the variable, rather I use a global. Same thing happens.
> > When it is set to REAL32 it blows up. STRANGE! That's one that can
> > drive you batty if you don't know what's causing the error. Nice job
> > catching it.
> >
> > Mike Groves
> >
> > -----Original Message-----
> > From: Barrie Walden [mailto:bwalden@whoi.edu]
> > Sent: Sunday, March 23, 2003 2:59 PM
> > To: VEE vrf
> > Subject: [vrf] Strange error message - Vee bug?
> >
> >
> > Hi folks,
> >
> > I have attached a small vee application that gives an error message that
> > doesn't seem appropriate for the object - in fact I don't think any
> > error message is appropriate.  The attachment is part of a data post
> > processing routine that successfully reads 10 or 20 thousand lines from
> > a file and then dies.  The data I have provided as hard inputs are the
> > values read from the file when the error occurs.  Notice the "-0.00";
> > changing this to "0.00" prevents the error which implies that asReal64(
> > ) handles -0 and +0 differently.
> >
> > I can also fix the problem in another way; the error will not occur if
> > the "Cdir" input pin is defined as a Real64 rather than Real32.
> >
> > Even knowing the cause doesn't help me to understand the error message.
> > I haven't reported this to Agilent but I will unless one of you can see
> > something I'm missing.
> >
> > Barrie


---
You are currently subscribed to vrf as: ken_colasuonno@agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@it.lists.it.agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Outcomes