• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Open Office for eCS-OS/2 2.4 Beta1

Started by Andi710, 2008.03.19, 08:18:09

Previous topic - Next topic

Andi710

It's good to be up-to-date with the OOo code base. Unfortunately text drag and drop still does not work :o(

saborion2

#1
In agreement 100%  :)  with you that; "It's good to be up-to-date with the OOo code base.  ;). The question is, How far are we away from being able to address the following "Spread Sheet Functionality":

Converting from Internal Rate of Return (IRR) to Economic Rate of Return (ERR)!!!

"Re: Concerning the issues with 1-2-3 that are talked about in the documentation you gave me, most of the issues are related to converting files between older and newer versions of product and converting documents between Lotus and Microsoft. Anytime a file is saved backwards or saved with an older file format than the format the file was created under, such as saving a 1-2-3 , 97 file for Windows 95 into a WK1 format for DOS, then naturally we are expected to loose certain features due to technology and features that are present now that were not present 8 - 10 years ago. Similarly, if we try to convert a file from Lotus into Excel or Excel into Lotus, due to differences in the products not every feature will be converted perfectly with the file filters that are available. Both Lotus and Microsoft create similar spreadsheet programs; however, there are several differences in both programs and these differences will remain to distinguish the products apart. We do try to design conversion filters that will allow as much of the file formats as possible to be exchanged and converted without disrupting the actual file design and format.

In one of your letters you made mention of the @IRR and @ERR functions in the 1-2-3 product. By design the @IRR (notably "absent" in Open Office) will calculate the Internal Rate of Return; where the @ERR is used in conjunction with other formulas, posted was an "ERR" showing an error was received in the calculations. As far as I can see in the program I cannot find an @ERR function that will allow us to calculate an Economic Rate of Return"

Best regards.


Andi710

Probably because 'internal rate of return' is one of the worst measures to base investment decisions on. Use NPV (Net Present Value) instead or, if you really want to be precise, a real option approach! ;o)

saborion2

You said; "Probably because 'Internal Rate of Return' is one of the worst measures to base investment decisions on. Use NPV (Net Present Value) instead..." Now, isn't that very funny since this is one of the Financial Analyses Tools that are used by the United Nation Industrial Development Organization (UNIDO). Here, follow the attached link and see for yourself. ;) :-

http://www.unido.org/doc/3383

http://www.win2biz.com/comfar/default.htm

http://www.npsnconference.ir/Files/File/REGISTFORM_05_2008.pdf

Question is: What do "you" know that the "folks" at the United Nations Industrial Development Organization (UNIDO) among others don't know.?

Good luck to you.
 

djcaetano

Quote from: saborion2 on 2008.03.19, 20:35:34
You said; "Probably because 'Internal Rate of Return' is one of the worst measures to base investment decisions on. Use NPV (Net Present Value) instead..." Now, isn't that very funny since this is one of the Financial Analyses Tools that are used by the United Nation Industrial Development Organization (UNIDO). Here, follow the attached link and see for yourself. ;) :-
Question is: What do "you" know that the "folks" at the United Nations Industrial Development Organization (UNIDO) among others don't know.?

  I miss IRR function too. BTW, AFAIK, IRR and NPV measure different things... it doesn't make sense (for me) exchanging one for another.

Saijin_Naib

#5
How about we get it to not be amazingly slow? I didnt know my 3.06ghz P4 with HT and 2gb of RAM would feel this slow opening OO, but it is. Its kinda inexcusably slow.

RobertM

Quote from: Saijin_Naib on 2008.03.20, 03:13:35
How about we get it to not be amazingly slow? I didnt know my 3.06ghz P4 with HT and 2gb of RAM would feel this slow opening OO, but it is. Its kinda inexcusably slow.

Enable the preload option/tool... that is how it is done on Windows IIRC - and will cut load times down considerably.

-R


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

No, I have it off in Windows XP, and it still starts about 2x as fast. I've posted the time comparisons here before in another thread. Also, I'm taking about the use of the program's GUI as well once it has finally decided that it wishes to load.

RobertM

#8
Quote from: Saijin_Naib on 2008.03.20, 05:17:56
No, I have it off in Windows XP, and it still starts about 2x as fast. I've posted the time comparisons here before in another thread. Also, I'm taking about the use of the program's GUI as well once it has finally decided that it wishes to load.


Hmmm....


  • What file system is it installed on? (HPFS/JFS/HPFS386?)
  • What type of video card (nVidia/ATI/other) and what video driver (SNAP/Panorama) are you using?
  • Is the XP version a GA version or a beta? (the OS/2 beta's presumably have lotsa debug code loaded, which will slow them down noticeably).




I have not compared it to Windows (and havent tried the latest beta), but the things I can tell you that I have noticed are:


  • OO on nVidia or Intel 845 chipsets (with SNAP - havent tried Panorama) is horrendously slow for any drawing, scrolling, updating (my PII 300 runs it faster than a 2GHz machine and nVidia card) - it's not OO, it's OO's reliance on crappy nVidia support by SNAP.

  • For OO (and Ceres Sound Studio - and presumably various other apps), there is a very noticeable speed increase when running on JFS.

    As an example my speed comparisons were with Ceres on HPFS386 (with a couple hundred megs of cache) and Ceres on JFS (with 64MB cache). Ceres, when editing audio, writes the Undo and processing buffers (entire copies of the current memory sets) to disk (unless you have gigs of RAM and tell it to use RAM - but the default is disk). JFS outperformed HPFS386 by a factor of almost 10.

    I'm guessing (especially from such hints that came with various versions of OO/2) that OO will also benefit from a noticeable speed increase from going to JFS... and in 99% of the OS/2 users case out there, it will be far more noticeable than mine (HPFS386 is definitely faster than HPFS - and I'd guess 99% of the OS/2 users are running plain HPFS).


  • Another odd thing I noticed is that it goes a little slower (loading) if Firefox (v2s) is also running - but that could simply be because this machine doesnt have much memory - and the two use large amounts requiring OS/2 to juggle memory around to provide contiguous segments or who knows what - (making that part up - but it sounded good and might explain that behavior)


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Robert Deed

All valid suggestions.  I believe it even recommends installing OO on JFS in the read me files.  In my experience the OS/2 port of OO are on par for any of the 3rd party ports, infact performance is much better then on Mac OS X (even though they basically just recompiled the linux build for mac X11.. I am starting to think that making a decent up to date hoblink/exceed PM x11 would be a great way to get apps quickly to OS/2 and then add OS/2 specific code in as time allows).  It is INCREDIBLY slow on Mac OS (I've tried both PPC and Intel versions on various macs, not to mention that mac is alot less hardware dependent then OS/2).  Obviously for any large graphical app you're going to want a video card which is supported ACCELERATED by SNAP.  Some people out here might like PANORAMA however panorama while being a great choice for a video card completely unsupported by snap is significantly slower then a full accelerated driver.  (I've tested between panorama on a ATI X1650 GT 512mb and a ATI Radeon Pro 9700 64mb.. and the 9700 is MUCH faster then the X1650 which would smoke a 9700 if it was accelerated). 

Otherwise like I've said, I have used many different versions of OO, Windows, Linux, OS/2, MacOS and the OS/2 builds on my machine (AMD Athlon X2 4000+, 2gb ram, 1tb Hitachi HD, JFS, ecs 2.0 RC4, ATI Radeon 9700 w/ Snap)  are on par with any other version I have used.  Infact the writer actually opens up faster on my OS/2 machine with quickstart off then it does on my wifes windows machine (same hardware except an x1650 gt) with quickstart on. 

Quote from: RobertM on 2008.03.20, 06:04:03
Quote from: Saijin_Naib on 2008.03.20, 05:17:56
No, I have it off in Windows XP, and it still starts about 2x as fast. I've posted the time comparisons here before in another thread. Also, I'm taking about the use of the program's GUI as well once it has finally decided that it wishes to load.


Hmmm....


  • What file system is it installed on? (HPFS/JFS/HPFS386?)
  • What type of video card (nVidia/ATI/other) and what video driver (SNAP/Panorama) are you using?
  • Is the XP version a GA version or a beta? (the OS/2 beta's presumably have lotsa debug code loaded, which will slow them down noticeably).




I have not compared it to Windows (and havent tried the latest beta), but the things I can tell you that I have noticed are:


  • OO on nVidia or Intel 845 chipsets (with SNAP - havent tried Panorama) is horrendously slow for any drawing, scrolling, updating (my PII 300 runs it faster than a 2GHz machine and nVidia card) - it's not OO, it's OO's reliance on crappy nVidia support by SNAP.

  • For OO (and Ceres Sound Studio - and presumably various other apps), there is a very noticeable speed increase when running on JFS.

    As an example my speed comparisons were with Ceres on HPFS386 (with a couple hundred megs of cache) and Ceres on JFS (with 64MB cache). Ceres, when editing audio, writes the Undo and processing buffers (entire copies of the current memory sets) to disk (unless you have gigs of RAM and tell it to use RAM - but the default is disk). JFS outperformed HPFS386 by a factor of almost 10.

    I'm guessing (especially from such hints that came with various versions of OO/2) that OO will also benefit from a noticeable speed increase from going to JFS... and in 99% of the OS/2 users case out there, it will be far more noticeable than mine (HPFS386 is definitely faster than HPFS - and I'd guess 99% of the OS/2 users are running plain HPFS).


  • Another odd thing I noticed is that it goes a little slower (loading) if Firefox (v2s) is also running - but that could simply be because this machine doesnt have much memory - and the two use large amounts requiring OS/2 to juggle memory around to provide contiguous segments or who knows what - (making that part up - but it sounded good and might explain that behavior)


RobertM

Oooh... I forgot a suggestion that may impact performance in OO and other apps (not Ceres - it uses it's own temp paths - which you can and should configure to use a JFS volume)... but I also move the swap file AND all temp directories to a JFS drive. Does wonders when a machine either (a) starts to swap to the swap file and/or (b) starts writing temp files to disk.

Having different disks on different controllers is a great way of speeding things up even more... IIRC, OS/2 can simultaneously do multiple concurrent disk writes - but two IDE drives on the same chain do not support such. SATA I think should since each is on it's own "controller".

And a final tech note... do NOT connect your IDE drive to the same ribbon cable as your optical drive (unless by some miracle you have an optical drive that supports ATA133 and the rest of the feature set the IDE HDD does)... doing so is a great way of slowing down the performance of the IDE HDD. It is better to have two IDE HDDs on the same cable than to have one sharing a cable with an optical drive. I dont recall exactly which feature that the HDD has (that the optical one doesnt) that is not usable in such a configuration - but it is a performance related one. As far as I have read, it was never fully rectified...


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Robert Deed

DOH! I completely forgot about that.  All my hardware is SATA, and with 2GB I hardly ever get any swapping.  In fact my swapper has stayed at its initial size since I installed ecs.  It is amazing to me how many people I know who built their own machines and put the HD and cdrom on the same controller.  I personally always keep my opticals on seperate channels if I can, copying from an IDE DVD-ROM to a IDE DVD-R is no fun if they are on the same controller channel.


Quote from: RobertM on 2008.03.20, 06:46:17
Oooh... I forgot a suggestion that may impact performance in OO and other apps (not Ceres - it uses it's own temp paths - which you can and should configure to use a JFS volume)... but I also move the swap file AND all temp directories to a JFS drive. Does wonders when a machine either (a) starts to swap to the swap file and/or (b) starts writing temp files to disk.

Having different disks on different controllers is a great way of speeding things up even more... IIRC, OS/2 can simultaneously do multiple concurrent disk writes - but two IDE drives on the same chain do not support such. SATA I think should since each is on it's own "controller".

And a final tech note... do NOT connect your IDE drive to the same ribbon cable as your optical drive (unless by some miracle you have an optical drive that supports ATA133 and the rest of the feature set the IDE HDD does)... doing so is a great way of slowing down the performance of the IDE HDD. It is better to have two IDE HDDs on the same cable than to have one sharing a cable with an optical drive. I dont recall exactly which feature that the HDD has (that the optical one doesnt) that is not usable in such a configuration - but it is a performance related one. As far as I have read, it was never fully rectified...

Saijin_Naib

Thanks for the general hardware hints, but I am fully aware of all these things, you forget I am a gamer and I build my rig from scratch :P Unfortunately, yes, I am using Panorama, but with Shadow Buffer On (performance akin to SNAP with Accel for most things). I know scrolling will be slow, but I'm not referencing that. I am using eCS 2.0 RC4 on a JFS drive, 8gb, WD IDE with UDMA 5/PIO4. My machine specs are in my sig, I have plenty of RAM. I'm commenting on the very long startup time VS OO for Windows, and how unresponsive the menus are, and how generally sluggish the program strikes me as being. If indeed this is a native app, then it by no means should be this pokey. I was under the impression it was hobbled by being emulated, but apparently this is not the case. Oh well, its the only option we have, but thats no reason to be complacent.

RobertM

#13
Well, then I would wait for the GA version... the last release of OO/2 I found the GA version a lot faster than the beta versions.

QuoteThanks for the general hardware hints, but I am fully aware of all these things, you forget I am a gamer and I build my rig from scratch

No... I just remember that when playing with Ceres, I was so into playing with it that *I* forgot all those things until about a month later when I got less enthused with using the app, and more interested in resolving it's performance bottlenecks.  ;D

So I figured just in case...  ;)


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

Haha, thanks :) I don't do anything intensive under eCS, so I would hope that my (admittedly modest in modern times) hardware will be enough. I mean, I can run Crysis, F.E.A.R, Half-Life 2, etc etc, so I really get rather miffed when an office application takes longer to open than a high-end game like Team Fortress 2. ??? Call me crazy, I know, but still :P