Fri 07 Oct 2016 11:22:56 PM UTC, comment #12:
Closing with "works for me" status.
|
Fri 07 Oct 2016 12:58:22 PM UTC, comment #11:
I'm pretty sure that the reason Octave just prints the value when there are no input/output arguments is because that's what Matlab used to do. It's easy enough to change, I suppose.
We have had bug reports about the actual values returned by computer in the past and decided not to change them. I'd really rather not change them in Octave, but I guess if we are not 100% exactly like Matlab in every way, then someone somewhere will be pissed about it.
No, there is not a 64-bit version on alpha.gnu.org yet but you are right that it would be good to have for testing.
Resources are limited. Can you support our work somehow?
|
Fri 07 Oct 2016 09:55:10 AM UTC, comment #10:
What about the output of computer():
http://www.mathworks.com/help/matlab/ref/computer.html
Octave returns this:
while Matlab returns:
Which makes me notice that, with Octave, computer() prints the output instead of returning it as an output argument.
[I realize I am hijacking this thread with a related but distinct issue, let me know if I should open a new bug report instead].
|
Fri 07 Oct 2016 06:32:51 AM UTC, comment #9:
Yes, this is indeed fixed in the 64bit version of 4.0.3 available from http://www.tatsuromatsuoka.com/octave/Eng/Win/
Thus, we can close this issue, I guess.
Is there already a 64 bit binary for the Release candidate available for download? I could not find it on ftp://alpha.gnu.org/gnu/octave, but it might be good to have it for testing.
|
Thu 06 Oct 2016 10:45:07 PM UTC, comment #8:
I haven't checked, but I guess this would be fixed by using the 64-bit binary instead? I intend to distribute both 32- and 64-bit binaries for Octave 4.2.
|
Thu 06 Oct 2016 10:30:19 PM UTC, comment #7:
I see. Then this is actually Microsoft's desired behavior and not a bug, because the current Octave binary on Windows is a 32bit one.
|
Thu 06 Oct 2016 10:20:50 PM UTC, comment #6:
This might be relevant:
http://stackoverflow.com/questions/1738985/why-processor-architecture-always-returns-x86-instead-of-amd64
|
Thu 06 Oct 2016 10:10:17 PM UTC, comment #5:
Hmm, on my Windows 7 system running in a VM, the value in the DOS shell is AMD64 but the value in Octave (CLI or GUI) is x86. I'm sure Octave is not setting this directly (PROCESSOR_ARCHITECTURE is nowhere to be found in the Octave sources), so some library that we use must be doing it? Hmm, which one?
|
Thu 06 Oct 2016 09:57:00 PM UTC, comment #4:
No, Matlab correctly returns the environment variable's value "AMD64". Octave only reports "x86".
|
Thu 06 Oct 2016 09:51:42 PM UTC, comment #3:
I think the value of an environment variable is outside the scope of Octave. If it is set to something, then Octave's getenv function should return it. That looks to be working.
I'd be curious to know whether it is different outside of Matlab. If so, then maybe Matlab sets it at startup? But I see no reason to do that.
|
Thu 06 Oct 2016 09:49:29 PM UTC, comment #2:
My environment variable actually says "AMD64".
|
Thu 06 Oct 2016 09:42:05 PM UTC, comment #1:
What happens if you check the value of the environment variables PROCESSOR_ARCHITECTURE from within the Control Panel? At least on my Windows XP virtual machine, the PROCESSOR_ARCHITECTURE variable is set to 'x86' already and so Octave is correct in returning that walue.
If I go and change the environment variable to something like "foobar", then Octave accurately reports that silly value instead when I use getenv.
|
Thu 06 Oct 2016 09:24:36 PM UTC, original submission:
On Windows 10 64 bit with a Core i7-4790K, calling in Matlab 2016b
returns
but on Octave, it returns
|