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

 
 

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

Submitted by:  None
Submitted on:  Wed 06 Feb 2013 07:24:32 AM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: ConfirmedAssigned to: None
Originator Name: ShaneOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.6.3
Operating System: Mac OS

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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

test this?

Carnë Draug <carandraug>
Project 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>
Project 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:

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>
Project 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>
Project Member
Tue 22 Oct 2013 06:39:01 PM UTC, comment #26:

mingw

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

mingw:

John Donoghue <lostbard>
Project 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):

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):

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>
Project 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>
Project 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:

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

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

After removing the second % from line 123:

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

In mingw, with units 2.0.2:

John Donoghue <lostbard>
Project 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>
Project Member
Mon 21 Oct 2013 10:48:10 PM UTC, comment #17:

Works for me in mingw:

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

That should be

Mike Miller <mtmiller>
Project 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

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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:

Does work with GNU units 2.00 and 2.02.

Mike Miller <mtmiller>
Project 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>
Project Member
Sat 20 Apr 2013 10:37:05 PM UTC, comment #5:

Michael Godfrey replied via email, reposting to tracker:

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>
Project 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-1.88:

units-2.00:

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>
Project 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>
Project Member
Wed 06 Feb 2013 02:58:59 PM UTC, comment #1:

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

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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 File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 22 Oct 2013 08:08:08 PM UTClostbardAttached File-=>Added units.patch, #29447
    Sat 19 Oct 2013 03:18:04 PM UTCmtmillerDependencies-=>bugs #40307 is dependent
    Sat 20 Apr 2013 09:39:23 PM UTCmtmillerStatusWorks 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
    Wed 06 Feb 2013 02:58:59 PM UTCjordighStatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup