This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Kspread Feature request: new cell type 'Range'

'range' would be a valueable addidtion to Kspread

Excellent. I could use this today!
33%
If it's there I might use it
No votes
It might be nice but not for me
33%
I can't see the point
33%

Total votes : 3


Tags: None
(comma "," separated)
mgerben
Registered Member
Posts
2
Karma
0
How often do we say 'That will cost 10 to 15 euro's'. Or 'we need 50 to 100 people'?


I would like to see a cell type 'range' to catch this concept.
Such a cell would have an upper and a lower value. One spreadsheet-cell would contain two values.

Ranges can be added, multiplied or averaged in combination with other ranges or ordinary cells.


For example: I wish to stay in a hotel.
A hotel costs between 20 and 50 a night;
I will stay for 3 nights.

Hotel price is a range.
The total cost will be between 60 (lower limit) and 150 (upper limit).
As you can see, the result of multiplying a range is again a range.

I change the number of nights from a fixed number to a range.
I want to stay 3-5 nights.
Then my hotel costs will be between 3x20=60 (minimum number of nights times lowest price) and 5x50=250 (highest price times maximum number of nights).
The result of multiplying 20-50 by 3-5 is 60-250.

Ranges can be added of multiplied to themselves, and to ordinary values. The result is almost always a range.
User avatar
RGB
Registered Member
Posts
346
Karma
0
OS
You can use two cells (one for minimum value, one for maximum) and operate with both columns at the same time.


RGB, proud to be a member of KDE forums since 2008-Nov.
And proud to be a kde user since 1.1.2
mgerben
Registered Member
Posts
2
Karma
0
Thanks for the reply.

Of course there exists a workaround.
But to do it like that means you have to design your entire sheet around it.

What I want is the option to have a sheet, and then decide that certain values are estimates - and see the whole estimate calculated through to the end.

It's like a date-field: You could split the date in three fields: Year, Month, Day - and do all the calculations yourself. Yet nobody complains about the existence of the date-type.

I am not saying there is no workaround to get similar results. I am talking about added value.
User avatar
RGB
Registered Member
Posts
346
Karma
0
OS
The main problem I see here is how to store those "data range": I cannot be completely sure, but I think this possibility is not implemented on the ODF standard (at least, I cannot find anything about this on Internet, let me know if I'm wrong!). Because ODF format is used by other apps (like OOo), there must be an agreement first. Of course it is possible, but many thing needs to happen before it is implemented. So, it is worth the effort? I'm not sure.
On the other hand maybe this is not that difficult: you can store complex numbers (formed by a "real" and a "imaginary" part) so it is possible to have two numbers in one cell...
Which in turn gives a "work-around": insert the minimum and maximum values as the real and imaginary part of a complex number... ;)
Just type
=complex(<minimum>;<maximum>)
and you will see
<minimum>+<maximum>i


RGB, proud to be a member of KDE forums since 2008-Nov.
And proud to be a kde user since 1.1.2


Bookmarks



Who is online

Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan