[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
970226: Porting UDunits to PC
- Subject: 970226: Porting UDunits to PC
- Date: Wed, 26 Feb 97 10:21:57 -0700
Arlindo,
>Date: Wed, 26 Feb 1997 11:59:51 -0500 (EST)
>From: Arlindo da Silva <address@hidden>
>Organization: NASA/GSFC
>To: address@hidden (Steve Emmerson)
>Subject: Re: 970226: Porting UDunits to PC
>Keywords: 199702221703.KAA06697
In the above message, you wrote:
> Here is what I get (I am just editing this by hand):
>
> > struct {
> > origin = 5.3853155396696e-322
> > factor = 0.00000
> > hasorigin = 0
> > power = {
> > [0] 0
> > [1] 0
> > [2] 0
> > [3] 0
> > [4] 0
> > [5] 0
> > [6] 0
> > [7] 0
> > [8] 0
> > [9] 0
>
>
> The "factor=0" is what makes utPrint() to return a NULL; it also gives NANs
> when used in utRaise(). Last night I was trying to trace where the apparent
> junk (origin=...e-322,factor=0) was coming from without much luck. My guess
> is that it could be related to the bison/utlib interface, but I am not sure.
Tough problem.
The parser calls units-handling functions in the file utlib.c. All I
can suggest is calling those functions (via a small program) and seeing
what they do. I think the steps to investigate are the following (based
on the `NAME INT' sequence in utparse.y):
UtUnit unit1, unit2;
utFind("m", &unit1);
utRaise(&unit1, 2, &unit2);
utCopy(&unit2, &unit1);
Hopefully, at some point one of the above function calls will mess-up.
At which point we can investigate further.
Let me know what you find.
--------
Steve Emmerson <address@hidden>