bugGNU Octave - Bugs: bug #38270, miscellaneous package: units...

 
 

bug #38270: miscellaneous package: units conversion from degC to K fails with units 1.0

Submitter:  None
Submitted:  Wed 06 Feb 2013 07:24:32 AM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Shane Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.6.3
Operating System:  * Mac OS Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 16 Nov 2016 07:27:34 PM UTC, comment #32: 

Closing this bug as fixed. If there are still problems with the units command on BSD or macOS systems in the future, this bug can be reopened or a new one filed.

Mike Miller <mtmiller>
Group Member
Thu 31 Oct 2013 06:55:58 PM UTC, comment #31: 

Seems this only needs to be tested on the old Mac version of units, with the also old version of units.dat file. Could someone with units 1.0 (version from 1993 still being distributed with Mac), whose top line of the the units.dat file has


/ $FreeBSD: src/usr.bin/units/units.lib,v 1.13 2002/07/09 08:47:03 joerg Exp $


test this?

Carnë Draug <carandraug>
Group Member
Wed 23 Oct 2013 05:48:46 PM UTC, comment #30: 

cool - on my system now:

>> test units.m

PASSES 4 out of 4 tests

>>


John Donoghue <lostbard>
Group Member
Wed 23 Oct 2013 05:37:16 PM UTC, comment #29: 

To John Donoghue:

the change you make for the non-linear conversion template for the old units file seems wrong to me. It would make the command:


"units x from" "to"


I committed it without the change on that line (I'm guessing changes on that line would not create an issue in your system as you're using units 2.0.2).

I also reorganized the code a bit to make it easier to add more alternative syntax later on.

To Vote 539:

I don't understand why you're getting that error. The current code should try the 'units "from(x)" "to"' syntax and if it fails, try 'units "x units" "to"'. If your system uses something else, can you submit a patch for it?

Carnë Draug <carandraug>
Group Member
Wed 23 Oct 2013 09:00:08 AM UTC, comment #28: 

On OS X 10.7 I'm still getting the same error output as from comment #21 with r12301.  I think that this version of units doesn't like arguments of the format "degC(100)" with parentheses and all.

I uploaded my units binary to http://octave-online.net/units-mac-default but I can't get it to run on Linux.  Maybe it would work on BSD?

Vote 539 <vote539>
Tue 22 Oct 2013 08:08:08 PM UTC, comment #27: 

Patch from last rev that works for me



(file #29447)

John Donoghue <lostbard>
Group Member
Tue 22 Oct 2013 06:39:01 PM UTC, comment #26: 

mingw


>> test units.m
units: only one '%' allowed in number format specification
units: invalid character (%) in width, precision, or type
units: invalid number format specification (%%.16g)
units: valid specification is %[flags][width][.precision]type
units: only one '%' allowed in number format specification
units: invalid character (%) in width, precision, or type
units: invalid number format specification (%%.16g)
units: valid specification is %[flags][width][.precision]type
  ***** assert (units ("tempC", "tempF", 100), 212)
!!!!! test failed
units: unable to identify correct syntax for non-linear conversion
>>


John Donoghue <lostbard>
Group Member
Tue 22 Oct 2013 06:37:24 PM UTC, comment #25: 

mingw:

>> test units.m
units: only one '%' allowed in number format specification
units: invalid character (%) in width, precision, or type
units: invalid number format specification (%%.16g)
units: valid specification is %[flags][width][.precision]type
units: only one '%' allowed in number format specification
units: invalid character (%) in width, precision, or type
units: invalid number format specification (%%.16g)
units: valid specification is %[flags][width][.precision]type
  ***** assert (units ("tempC", "tempF", 100), 212)
!!!!! test failed
units: unable to identify correct syntax for non-linear conversion
>>
verbatim-

John Donoghue <lostbard>
Group Member
Tue 22 Oct 2013 06:29:18 PM UTC, comment #24: 

So I got my hands on a MacOSX system to test this with the non-GNU units v1.00 and I get a different output from the one mentioned on message #4 (and one very close to the GNU units):


$ units -v

  units version 1.0  Copyright (c) 1993 by Adrian Mariano
                    This program may be freely distributed
usage: units [-f unitsfile] [-q] [-v] [from-unit to-unit]
$ units degC K
    * 1
    / 1
$ units "degC(100)" K
unknown unit 'degC(100)'
conformability error
    1 degC(100)
    1 K


I then figured that this is not dependent on the units version, but on the version of units data file. I found someone with a different version of MacOSX and could replicate the output from message #4. The difference is in the units.dat file (mentioned at the end of units man page):


/ $FreeBSD: src/usr.bin/units/units.lib,v 1.13 2002/07/09 08:47:03 joerg Exp $
/ $FreeBSD: src/usr.bin/units/units.lib,v 1.19.2.1.2.1 2009/10/25 01:10:29 kensmith Exp $


I pushed another change (r12301) which tries both syntax of non-linear conversion. There are a couple of tests in the function file so please run "test units.m" and add your own as well.

Carnë Draug <carandraug>
Group Member
Tue 22 Oct 2013 05:01:50 PM UTC, comment #23: 

I don't see a reason to distribute GNU units ourselves. That would be the same as setting GNU units as dependency (instead of any version units). The difference between 1.88 and 2.00 seem minimal, the main problem is the Mac version which is from 1993!!

Carnë Draug <carandraug>
Group Member
Tue 22 Oct 2013 06:06:42 AM UTC, comment #22: 

What is the feasibility of bundling the GNU Units code with Octave Miscellaneous as a dependency?  We can call that local binary when a user runs the `units` function from within Octave.  Then we won't need to worry about compatibility issues any more.

Vote 539 <vote539>
Tue 22 Oct 2013 05:58:48 AM UTC, comment #21: 

Thanks for working on this bug.  Here's the output of Carnë's r12300 on OS X and units 1.0:


octave:1> units("degF", "K", 90)
error: units unable to parse non-linear conversion `unknown unit 'degF(90)'
conformability error
        1 degF(90)
        1 K
'
error: called from:
error:   /private/tmp/units/units.m at line 90, column 11


The middle part of that message happens to be the output from units 1.0.


$ units  "degF(90)" "K"
unknown unit 'degF(90)'
conformability error
        1 degF(90)
        1 K


Vote 539 <vote539>
Tue 22 Oct 2013 04:21:43 AM UTC, comment #20: 

After removing the second % from line 123:


>> units('degF','C');
error: units: conformability error
0.5555555555555556 K
1 A s
>> units('tempF','tempK')
ans =  255.93
>>


John Donoghue <lostbard>
Group Member
Tue 22 Oct 2013 04:02:04 AM UTC, comment #19: 

In mingw, with units 2.0.2:

>> units("degF", "K", 90)
units: only one '%' allowed in number format specification
units: invalid character (%) in width, precision, or type
units: invalid number format specification (%%.16g)
units: valid specification is %[flags][width][.precision]type
ans =  50.000
>> units("degF", "K", 90)
ans =  50.000
>>


John Donoghue <lostbard>
Group Member
Tue 22 Oct 2013 03:52:18 AM UTC, comment #18: 

Ok. I pushed two more change (r12299 and 12300). Could someone with other versions give it a try?

The second change tries to implement non-linear unit conversion. I'm not sure if it will work in the old version from 1993 that is being shipped with MacOSX but before it was not working at all so I guess that's still an improvement.

On another note, apparently the non-GNU version sees degC and K as temperature units, while in the GNU version of units, one needs to use tempC and tempK. This means that the same Octave code, running on different systems with different versions of units, will have  very very different results.

Carnë Draug <carandraug>
Group Member
Mon 21 Oct 2013 10:48:10 PM UTC, comment #17: 

Works for me in mingw:


>> file_in_path (getenv ("PATH"), sprintf ("units%s", octave_config_info
("EXEEXT")))
ans = C:\MinGW\msys\1.0\home\jdonoghue\mxe-octave\usr\bin/units.exe
>>


John Donoghue <lostbard>
Group Member
Mon 21 Oct 2013 10:07:37 PM UTC, comment #16: 

That should be


file_in_path (getenv ("PATH"), sprintf ("units%s", octave_config_info ("EXEEXT")))


Mike Miller <mtmiller>
Group Member
Mon 21 Oct 2013 09:56:09 PM UTC, comment #15: 

No need to use "command -v units", we already have the file_in_path function. Something like


file_in_path (sprintf ("units%s", octave_config_info ("EXEEXT")))


should work. Then you can call units --version, however keep in mind that the "GNU" string didn't appear until some version > 1.53, where 1.53 is the earliest version on ftp.gnu.org. Version 1.53 does support the -o option, but version 1.0 does not.

If we want to support units on stock OSX, which is what this bug report was about, then units has to be called with no options, just the two unit names, and the different output has to be parsed, as I posted in comment #4.

Mike Miller <mtmiller>
Group Member
Mon 21 Oct 2013 09:12:56 PM UTC, comment #14: 

According to the units webpage, active maintainer (and where bugs should go) is adrianm@gnu.org.

A real quick look at the units.c code, it returns 3 o a memory error.

In mingw, just use units --version ?

John Donoghue <lostbard>
Group Member
Mon 21 Oct 2013 08:41:29 PM UTC, comment #13: 

The problem is that `units -v` will exit with 3 instead of 0. I have reported this bug to Debian because I couldn't find a bug tracker for GNU units.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726960

So we are using `command -v units` which apparently is a more standard way of doing it anyway. How can you check this in windows? If you offer an alternative, we could do

if (ispc())
  ## do what you suggest
else
  ## check with command -v
endif

The exit value of 127 comes from not finding a command. I guess I could that to check if units is installed (exit with 127 if not available) but then what if units is installed but fails for some other reason? I'd rather be checking something for success than a single specific error.

Carnë Draug <carandraug>
Group Member
Mon 21 Oct 2013 08:12:26 PM UTC, comment #12: 

'command' is not a known executable for the system() call in Windows.

John Donoghue <lostbard>
Group Member
Mon 21 Oct 2013 06:30:18 PM UTC, comment #11: 

I'll take back that comment - there is command - its failing for me, returning 127 even though units is in the path :)


John Donoghue <lostbard>
Group Member
Mon 21 Oct 2013 06:24:58 PM UTC, comment #10: 

I tried running in mingw (after  compiling units 2.0.2) and found another issue that is I guess just ming related, in the compact_option function, where it fails:
Verify that GNU units is installed in the current path.

system ("command -v units") fails as it doesn't appear to know what 'command' is.




John Donoghue <lostbard>
Group Member
Sun 20 Oct 2013 11:35:29 PM UTC, comment #9: 

I have made further changes (revision 12298) that should hopefully make it work. About non GNU versions of units I made it issue a warning instead of an error. Could someone test this?

Carnë Draug <carandraug>
Group Member
Sun 20 Oct 2013 10:38:57 PM UTC, comment #8: 

I checked the NEWS file from GNU units and the compact and one-line options were added in 1.86 (10 Nov 2006). Was there anything similar to that before? Is there anything for non GNU versions of units? Any documentation for it at all?

Carnë Draug <carandraug>
Group Member
Sun 20 Oct 2013 07:42:35 PM UTC, comment #7: 

Here are some errors:

Does not work with non-GNU units, e.g. units 1.0 which is present on OSX systems. This may be fine, but it should probably check something like "units --version" to make sure it's GNU first, error out if it's not.

Does not work with GNU units 1.53:


/home/mike/src/units-1.53/units: unrecognized option '--compact'
/home/mike/src/units-1.53/units: unrecognized option '--one-line'


Does work with GNU units 2.00 and 2.02.

Mike Miller <mtmiller>
Group Member
Sun 20 Oct 2013 06:56:35 PM UTC, comment #6: 

I have just pushed a change (revision 12290) that should fix some of the problems mentioned.

As my version of GNU units was 1.88 and didn't had any problem, I'm unsure if it actually does fix. Could others please test it? Please see https://sourceforge.net/p/octave/code/HEAD/tree/trunk/octave-forge/main/miscellaneous/inst/units.m

In addition, it should be able to identify attempts to non-linear conversion and give an appropriate error.

Carnë Draug <carandraug>
Group Member
Sat 20 Apr 2013 10:37:05 PM UTC, comment #5: 

Michael Godfrey replied via email, reposting to tracker:

>> full definition of nonlinear unit conversions, so even when the syntax error
>> is fixed the conversion between degC and degK or degF will not be correct.
> What?


Conversion between degrees F and C and K are nonlinear conversions because 0 in one unit is not zero in another unit. See units(1) http://manpages.ubuntu.com/manpages/quantal/en/man1/units.1.html.

The Octave units function does not handle nonlinear conversions correctly, but that is a separate bug. This bug is about Octave throwing an error because it can't parse the output of different versions of the units program.

Mike Miller <mtmiller>
Group Member
Sat 20 Apr 2013 09:39:23 PM UTC, comment #4: 

I've checked 3 versions of the units program and confirmed that they do have different formats that the units function does not handle.

units-1.0 (fetched from http://www.opensource.apple.com/source/misc_cmds/misc_cmds-31/units/):

$ units degC K
         (-> x*1 +273.15)
         (<- y*1 -273.15)


units-1.88:

$ units degC K
        * 1
        / 1


units-2.00:

units degC K
Currency exchange rates from 2012-06-06
        * 1
        / 1


Only versions greater than 1.0 and less than 2.00 currently work with the units function.

Also note that no versions since 1.53 (when units became GNU units) output the full definition of nonlinear unit conversions, so even when the syntax error is fixed the conversion between degC and degK or degF will not be correct.

Mike Miller <mtmiller>
Group Member
Wed 27 Mar 2013 07:43:58 AM UTC, comment #3: 

It's strange how we are all getting different results when running this command.

It appears that units.m is running the `units` command.  Here is the output of `units "degF" "degK"` on my installation of units:

$ units "degF" "K"
(-> x*0.55555556 +255.37222)
(<- y*1.8 -459.67)

Here is my version of the `units` utility:

$ units -v

  units version 1.0  Copyright (c) 1993 by Adrian Mariano
                    This program may be freely distributed
usage: units [-f unitsfile] [-q] [-v] [from-unit to-unit]

I am running OS X and using the default installation of units.

For the record, the correct conversion from 90 degF to K is 305.372 K.

Vote 539 <vote539>
Sun 24 Mar 2013 12:01:48 PM UTC, comment #2: 

On dev octave, misc-1.2.0, and units-2.00-2.fc18.x86_64, I get output:

ctave-cli:2> units("degF", "K", 90)
error: parsing units output "Currency exchange rates from 2012-06-06
        * 0.55555556
        / 1.8
"
error: called from:
error:   /usr/share/octave/packages/miscellaneous-1.2.0/units.m at line 49, column 20
octave-cli:2>

John Donoghue <lostbard>
Group Member
Wed 06 Feb 2013 02:58:59 PM UTC, comment #1: 


octave:1>  units("degF", "K", 90)
ans =  50.000


Version 1.2.0 of miscellaneous package. Which version are you using? (pkg list)

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Wed 06 Feb 2013 07:24:32 AM UTC, original submission:  

Using the units() function available in the Miscellaneous OctaveForge package to convert to Kelvin produces a syntax error.

A code example should illustrate this bug pretty simply:

octave:11> units("degF", "K", 90)
parse error:

  syntax error

>>> y = x*0.55555556 +255.37222);
                               ^

parse error:

  syntax error

>>> y = x*0.55555556 +255.37222);
    ^

error: called from:
error:   /path/to/octave/miscellaneous-1.2.0/units.m at line 52, column 5

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29447:  units.patch added by lostbard (1KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by vote539 (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-16 mtmiller StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2013-10-22 lostbard Attached File- Added units.patch, #29447
    2013-10-19 mtmiller Dependencies- bugs #40307 is dependent
    2013-04-20 mtmiller StatusWorks For Me Confirmed
        SummaryUnits conversion from degC to K has syntax error miscellaneous package: units conversion from degC to K fails with units 1.0
    2013-02-06 jordigh StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code