octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45498] Minor bugs with xlswrite from package


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #45498] Minor bugs with xlswrite from package io-2.2.8
Date: Wed, 08 Jul 2015 21:25:01 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1

Update of bug #45498 (project octave):

             Assigned to:                    None => philipnienhuis         
        Operating System:       Microsoft Windows => Any                    

    _______________________________________________________

Follow-up Comment #1:

Thanks for the extensive testing & reporting.

As to bug #1: Should be an easy fix, I'll look into it soon.

As to bug #2: This was an explicit choice from the very start of the
spreadsheet I/O in Octave's io package.
It was made to protect existing cell contents outside the specified range
against accidental overwrites when arrays had been silently extended by
over-indexing (something that I often saw happening at my work).
I was never fond of this and other choices made by Matlab (for another
example: that what happens when writing arrays smaller then the specified
range - the "unused" cells in the specified range are filled with bogus info
that screwed up ensuing operations for me).  Much of ML behavior is actually
dependent on MS-Excel that ML relied on from the start.

One workaround for you until some next io release would be to assess the array
size in each cycle and then compute the current range-to-be-specified using
calccelladdress() (also in the io package).

For me as developer an option would be using the argument "spsh_opts" that is
called in the oct2xls.m function (that is invoked by xlswrite). xlswrite could
call oct2xls.m with some setting for mimicking Matlab behavior (and overriding
the IMO more sensible behavior now in io).
I think such a trick could be a good solution to try to mimic much other
Matlab behavior in xlswrite and xlsread, esp. as there are plans to move the
entire spreadsheet I/O into core Octave.

OS -> any


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45498>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]