The hexrep function irritated me a bit by being sorted LSB->MSB and not working for long doubles. I had constructed a re-sort, but couldn't get it to work for long doubles either. Now I saw by chance that there is a hex-format-specifier for printf in vanilla-C, 'A', which produces quite
It seems to me that fresh pulls of gnumeric into existing installs require a 'make clean' before the build since sometime after 2022-09-21, else t2001-func-help.pl fails with:
't2001-func-help.pl: Checking function help text sanity.
Differences between actual and expected on line 5:
Actual :
according to https://support.microsoft.com/en-us/office/ceiling-function-0a5cd7c8-0720-4f0a-bd2c-c943e510899f Excel rounds negative numbers differently:
'If number is negative, and significance is **negative**, the value is rounded **down**, away from zero.
If number is negative, and
the 'Defining New Functions' page in the manual appears empty in 'https://help.gnome.org/users/gnumeric/stable/sect-extending-functions.html.en', perhaps someone can add a chapter similar to the text below which made it for acsglster to implement his changes.
For those interested in the
hello @all,
it would be nice if someone could check that '=1125899906842624.25 ' changes to
and displays
1125899906842624.**3** as cell value, but in the formula bar, in edit-cell ( F2
) and in 'get.formula'
1125899906842624.**2** is used. ( To exclude that it is an error of my system.
hello @all,
IMHO it need not be that the result of '=log( 8, 3 )' is off by two ULP.
( it is calculated to
1.892789260714371923910E00 while '3' re-powered with that value becomes only
7.996447286E00 , and even 3 powered to the next representable double
all ok, me bad, think I found it, was a misunderstanding of the branching /
switch logic in src/expr.c/bin_arith/GNM_EXPR_OP_EXP.
searched for but couldn't find a discussion / decision if below would be
meaningful for gnumeric ...
think gnumeric's 'three argument notation' for 'power'
hello @all,
for private fun, Calc / Excel compatibility and easier cross-system-testing I'd like to implement evaluation of '= (-8)^(1/3)' -> '-2'.
I managed it for 'power' ( by patching goffice and plugins/fn-math/functions, but despite 'EXPR_OP_EXP' seems piped through gnm_power it still
yes, I know, I understand,
my thoughts are:
1. How do we get tests that are suitable for 'long'?
2. do the current tests hinder improvements?
( suppose an error in the program or e.g. a library has led to a weak reference ... the error is not noticed because the references are not
>> - how to deal with / construct tests for functions / ranges where 'long' and
>> 'double' version have justified different results?
( how to build tests which allow / demand improved results, but accept
'double accuracy results' when using double datatype? )
let me give it an
as a general philosopy I'd think: UI-use and data exchange -> mimic Excel and Calc, questionable calculations / wrong results / truncated precision / faking -> don't.
in that sense I see two - intentional? - deviating behaviors:
- Calc keeps the paste buffer after 'crtl-x - ctrl-v', you
but not yet clear to me:
- should 'trig.xls' be subject to a test, or do we have enough testing for trigonometric functions in other tests, e.g. that for complex numbers?
- how to deal with - construct tests for functions / ranges where 'long' and 'double' version have justified
as often with gnumeric, you ( I ) think to have a good idea ... it's already in ...
there is a function 'sinpi' which calculates sin for multiples of 휋 to better accuracy. same for cos and tan, not for asin, acos, atan.
IMHO it's still considerable to change the results of sin(x*pi()),
tag, 29. Mai 2022 um 11:43 Uhr
Von: "Steven D'Aprano"
An: "newbie nullzwei via gnumeric-list"
Betreff: Re: Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,
On Sun, May 29, 2022 at 11:14:02AM +0200, newbie nullzwei
2022 um 05:27 Uhr
Von: "John Denker via gnumeric-list"
An: "Gnumeric Forum"
Betreff: Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,
On 5/27/22 9:26 PM, newbie nullzwei via gnumeric-list wrote:
> In my double ve
hello @all,
I have spotted a sample sheet 'trig.xls', not evaluated by any test? intentional? is there another test checking trig functions?
In my double version tan(pi()/2) fails with 16331239353195370 instead of the reference 16324552277619072, tan(3/2*pi()) and the negative values
hello @ all,
four little questions:
Is it correct:
'GNM_FORMAT_g' produces decimal for some range and scientific output with small 'e', whil 'GNM_FORMAT_G' uses capital 'E'?
and if so: why is which 'e' vs. 'E' format preferred for which use case?
And where is it controlled that general
eric Forum"
Betreff: Re: Aw: Re: need help in some points to get gnumeric 'long' mature. introspection, GDA support, GNOME-DB support, Psiconv, PDF documentation.
Le lundi 02 mai 2022 à 06:20 +0200, newbie nullzwei via gnumeric-list a
écrit :
>
> hello Jean,
...
eed help in some points to get gnumeric 'long' mature. introspection, GDA support, GNOME-DB support, Psiconv, PDF documentation.
Le lundi 02 mai 2022 à 06:20 +0200, newbie nullzwei via gnumeric-list a
écrit :
>
> hello Jean,
...
>
Try apt-get i
hello Jean,
thanks for your fast response :-)
>> Introspection
> GObject Introspection does not support long double as far as I know, so
> you most probably need to choose between introspection and long double.
I'll put it aside for the moment, will still try to learn about
after some more investigation:
my system lacked the capa of correctly building 'perl' and 'perl-loader' after some messing around with perl
( removing perl in an attempt to go back to an old version, never try this at home unless you have a qualified
full system backup ).
Afterwards i
I've been trying to get gnumeric 'long' out of the 'experimental' state for some time now,
and have come quite far. To make this round I still need help with some peripheral points,
see the result of my configuration log attached at the bottom of this post.
TIA for any help!!
-
not the fields i know much about, thus more questions than 'issues':
1.) does gnumeric use parallelization - 'threading'? distributing independent tasks on multiple CPU cores? I just spotted that the recalculation of sheets I'm using for performance comparisions is done using mostly only
hello Andreas, thanks for your input,
h ...
not too easy to deal with excel, either i'm confused or they contradict themself.
support.microsoft.com - FLOOR function:
either this: I.) 'Rounds number down, **toward zero**, to the nearest multiple of significance.',
(think that's mimiced
not deeply investigated, thus more a question than an issue:
t6590-samples test sends '=floor(0.5)' in an xlsx roundtrip and gets back '=rounddown(0.5,0)'.
same happens to calculating cells in a sheet.
while '=floor(0.5,0.15)' comes back unchanged.
is there any rationale in changing
found it, sorry for late, old bug, still open,
see: https://gitlab.gnome.org/GNOME/gnumeric/-/issues/329,
the 'No samples for ...' might have creeped in unnoticed because
the errors are supressed in general,
perhaps my observation can help to solve, will follow up in #329,
Best Regards,
b.
hello @all,
probably silly question, but actually driving me nuts ... hope for simple help ...
all results in my various patched and original 'standard double' and 'long' versions log fails
for this test as shown below I.) ( plenty times 'No samples for ... ' and the roundtrips split
the sheet
problem vanished at some point, either on fresh installs or when i solved another problem that my UI was somewhat messed up, window titles gone, mouse cursor different, totally weird, problem was most likely something in the .cache dir of my user profile ... both points might be related or not
hello @all,
do we have such, or are there any hints how it should be implemented if I need to code it?
or an experienced dev who could make it in 'gnumeric style'?
best i could find is:
libgnumeric.c: RLIM_INFINITY,
options.c: infinity = 1,
and some functions dealing with
hello @all,
for unexperienced users contributing seems to have more hurdles than expected,
it starts with GitLab vs. GitHub, https vs. ssh, read only mirrors and so on, and
doesn't stop when gitlab proposes a 'GDK' on a 404 page.
hello @all,
think I'm growing old, can't tell for sure:
1.) - did gnumeric have 'ctrl+cursor' shortcuts to jump to the end of the current block of filled or empty cells and it's gone at some point in time?
2.) - doe's gnumeric have that feature and i'd mess up my system?
3.) -
hello @all,
absolute minor quirk, don't know who is in charge of such,
the maual at
lists ctrl-$ twice:
Ctrl-$ Formats the current selection with the default currency
...
Ctrl-$ Formats the current selection as the default currency
Best Regards,
b.
hello @all,
I somewhat miss the macro capabilities of Libreoffice ...
the following task: in a cell a tolerance value must be adjusted until a cell dependent on it reaches a certain step value. In calc I had built a macro which increases the cell value by one, held the thumb on
... and now i got the opposite effect, opening a file produced cells with 'double size'??? mysterious: the same user, computer, session ... two terminals open, both running mc as file manager, starting gnumeric with a macro from one Terminal and then opening a file: fat cells,
hello @all,
whatever step at whatever moment had pested some of my files with tags instead of , and similar with halved values for the columns.
As i couldn't find a point to reset that ... :-(
save uncompressed *.xml,
open in VS code,
search and replace,
save, reopen in
hello @all,
in the meanime I had more files without problems than with ... ??? it might be, can't tell for sure,
that the issue affects files which:
- are, or have sometimes been in their history, stored in *.ods format???
and / or
- have been touched with a gnumeric 'long double'
hello @all,
Two questions about the Gnumeric tests:
( I'm trying to see how well they work with a 'long' version )
1. could someone please check if it is correct that statfuns.xls in cell F22 calculates
15.0750001 as average of 33.9; 23.3; -1.3 and 4.4? And that this
hello @all,
minor issue:
a cell formatted as Number: 'Scientific', Decimals places: 18, 'Minimum number of exponent digits': 3, 'Always show exponent sign': checked, 'Use superscript': unchecked,
after save as *.ods ( strict conformance ) and load back frequently has the
hello @all,
doe's somebody know about and can help me with a code pointer?
( I'm quite sure MW can, but as well think he has lot's of other more important stuff to do. )
I want to - try to - get the tests (make check) passing with a long double version, and for that
purpose need
hello @all,
sorry for insisting on an old issue, IMHO it's quite important.
setting the export length for double values for e.g. odf / ods files to fixed 17 digits ( 21 for long? ) produces compatibility problems, see attached sheet. Sorry if any display format issues, '4k' seems not
hello @all,
IMHO it's not big enough an issue to open a ticket,
'make check' failed with
make[2]: *** No rule to make target 't1107-ilog.pl', needed by 't1107-ilog.pl.log'. Stop.
works better after changing all occurences of 't1107-ilog.pl' to 't1108-ilog.pl' in
hello @all,
I tried to use '=value( text( x, "0.0" ) )' and similar to check results of my 'improved calculations' and control whether rounding worked correctly or went wrong.
That worked fine until i had to compare against 1.45 . the binary 'nearest' representation for 1.45 with IEEE
hello @all,
!!! --- sorry, i wrote too fast, rechecking unveiled that it wasn't 'pow' but 'exp10l' being 'clean' with intel compiler, sorry. --- !!!
find attached the program to recheck.
i can't say why it is, may be they just use the same algo for 'exp10l(x)' and '1Ex'?? or use another
question in short: is there an easy / prepared way to compile gnumeric with another compiler? For example with 'clang' or 'intel'?
i have a little issue that POW or scientific strings are imprecise, they don't match for e.g. 10^23 and 1E23 in gnumeric with doubles.
it's less a gnumeric but
... :-) :-) :-)
Best Regards,
and @John Denker: thank you very! much :-)
b.
---
Gesendet: Mittwoch, 22. September 2021 um 14:44 Uhr
Von: "newbie nullzwei via gnumeric-list"
An: "John Denker" , "Gnumeric Forum"
Betreff: question about 'WHENCE' setup for second independent develop
hello @all,
want to learn about issues and pushing patches, have a very little change and tried:
@:/usr/src/gnome/gnumeric/plugins# git push origin master
Username for 'https://github.com': xx...@xxx.xx
Password for 'https://xx...@xxx.xx@github.com':
remote: Support for
hello @all,
for the problem described below and mailed 2021-09-25 there is some progress, the values (some of) which cause problems on import are not defined as '123456787' in e.g. samples/applix/samples.as, but as '12345.6787', which with english locale is 'nopro', but with german locale
hello @all,
I'm still trying to get a clean tested! gnumeric version up and running, and in that have some fails in the testsuite complaining 'SHA1 new is: xx, expected was: yy -> FAIL' e.g. for the 'applix import'.
I tried a 'manual test' with 'data - import -
hello @all,
i tried to come over the problem with 'too long and thus not accurate values' stored by gnumeric for 'doubles' in the test files, by restricting values to 16 significant decimal digits for write to *.ods files. not a final solution, but a step.
now i can run the tests, and with
hello @all,
to get it stramlined and regarding some difficulties between gnumerics testsfiles and a 'long-double-enabled' version i made a complete restart from scratch.
that gave the opportunity to run the testsuite against a 'clean' version (git checkout master | git pull origin master |
hello @all,
have an addition to the question:
repeated:
storing values in files pretending higher precision than they really have (in the originating fp-format) leads to compatibility problems with software using different precision for values. one of the simpliest cases:
the decimal value
hello @all,
ok, one problem identified which i had seen before, a 'long double' version reads in nonsense for fractional values stored by a 'double' version,
e.g. '=prob({0,1,2,3},{0.1555,0.4000222,0.2000111,0.2999889},2)' instead of
hello and thank you @Morten,
you are an excellent diagnostician and helper :-)
I could swear that I did that, 'F9', several times because I know the same problem from LibreOffice ... but now that I did it again on your advice I see the error ... great,
'attachement' ... me blind? probably
hello @list, thank you @Morten,
found and executed it (tests), got some fails and some 'success' as in attached log (shortened reg. list size restrictions), i'm confused as the results say something about e.g. '#NUM!' which looks like that that part was! run and failed in run (not in call), but
hello @Forum, hello @John Denker,
i'm trying to develop something for decimal correct math for gnumeric, and got the very useful tool 'WHENCE' from @John Denker which enables to maintain an independent development version while the standard gnumeric remains untouched and is in place for
hello @all,
i'm working on some small changes and for tests often have two or multiple windows open which show similar calculations but with different versions of gnumeric ... looking smilar in total and getting me confused because if have no 'quick view' which is which.
I'd like to be
hello @all, many many thanks to Morten,
I can hardly tell how happy I am that I could contribute something to this outstanding project ... very happy!
I can hardly adequately appreciate or even express how! thrilled I am how much meaningful wisdom has been implemented into this outstanding
hey hey,
my learning curve goe's up ?!?! (all below 'WIP', may include errors).
I can confirm comments like:
'Long double support is experimental -- expect problems'.
in e.g. configure(.ac), but made some progress, see below.
autogen.sh or configure with '--with-long-double' went into
hello @all,
please have patience with my inexperience ...
gnumeric can use 'long doubles'? but by default this is 'off'?
at different places in the program 'GNM_WITH_LONG_DOUBLES' is asked, and in different configuration files it can be set ... what do I have to enter where and which
hello@all,
am i at least in a warm area for my wishes with parser.c, expr.c and GNM_EXPR_OP_ADD ?
testing not yet found :-(
best regards, b.
---
hello @all,
my 'decimal-corrector' improves more and more, and i need to test it out,
with having a special function in a sheet i have
hello @all,
my 'decimal-corrector' improves more and more, and i need to test it out,
with having a special function in a sheet i have played enough, IMHO it works,
as i - yet - haven't found or got a hint to replace e.g. 'FADD' in total (too difficult?) i'd be very thankful for a
hello @Morten, hello @all,
thanks for your input, complex stuff, newbies like me would need a simple sample ... will try to find one,
in the meantime i found another - better? - solution with using 'rint' in the process of rounding, and now have (complex) calculations producing better results
ice is a library. You cannot call Gnumeric functions from Goffice.
Andreas
Sent from my Galaxy
Original message ----
From: newbie nullzwei via gnumeric-list
Date: 2021-09-07 08:50 (GMT-07:00)
To: geb...@mousecar.com, Gnumeric Forum
Subject: Aw: Re: simple?
before returnung it.
TIA for any help.
b.
Gesendet: Montag, 06. September 2021 um 18:48 Uhr
Von: "kf"
An: gnumeric-list@gnome.org
Betreff: Re: simple? c-coding / gnumeric coding style question ...
On 9/5/21 1:18 PM, newbie nullzwei via gnumeric-list wrote:
>
> hello @all,
>
hello @all,
i'm not a coder but trying to adapt some routines for small improvements in rounding and am stuck at the following point:
in functions.c i have the routine? function? 'gnumeric_rounddown',
i'd like to call that function from inside the function 'gnumeric_round' and compare the
hello @all, hello @Morten, hello @John Denker,
i've tried to code two functions 'bin_range' and 'dec_range' to provide the functionality i'm looking for,
and would be happy if someone experienced can take the time and have a look on it.
i started an 'issue' for it in
hello @all, hello @Morten,
Morten pointed out:
> "There are two types of rounding in Gnumeric: the rounding functions
such as ROUND. These change the values. Then there is the rounding
implied by attaching a format to a cell. That does not change the
value, only its display:"
theese roundings
hello @John Denker,
took some time but got it up and running, have to play with it and learn, looks very useful so far ... :-)
a question at you or others ... i'd like to try an attempt to get rid of 'zombie values', can anyone give my a short description which functions handele:
- keyboard
hello Morten,
acc. to a proposal of John Denker to work around wrong floor() results for 'zombie values' by
floor(x) < x ? floor(x) : floor(x) - 1;
i'd try to put it into goffice/goffice/math/go-math.c, and it seems to work.
would you mind to check the code:
---
thank you,
you are right,
but then frexp() calculates something different to 'extracting the parts (sign, mantissa and exponent) of the IEEE double representation',
(IEEE double mantissa for normalized values has to be [1 .. 2[), may be frep() calculates exactly half the mantissa and exponent
thank you, accurate analysis and nice visualization,
exactly such inconsistencies I would like to clear up.
This one may be a bit less inaccurate than it appears at first glance, 'int()' rounds positive and negative values 'towards negative infinity', while the granularity of floats /
thank you John,
> I assume you are trying to emulate the C function frexp().
almost, what I really want is to use this function 'in the code' to construct a function 'bin_range' which is available in the code and in sheets. I had found it in the meantime, but reaped compiler errors again ...
hello @ Steven,
> Do you know for a fact that Gnumeric implements its rounding by
multiplying 0,344 * 1E16 or are you guessing?
from functions.c / gnumeric_round:
gnm_float number = value_get_as_float (argv[0]);
gnm_float digits = argv[1] ? value_get_as_float (argv[1])
the value is not changed, what is displayed to you as 0,3 is 0,30004 in the background.
best regards,
b.
Gesendet: Mittwoch, 07. Juli 2021 um 12:03 Uhr
Von: "Steven D'Aprano"
An: "newbie nullzwei via gnumeric-list"
Betreff: Re: Re: Re: deco-Math project, step 00
hello @John Denker,
> There are issues with floating point.
agree,
> AFAICT the real topic here is not a gnumeric issue,
let's concentrate on what gnumeric can! do:
- 'rounddown' and 'roundup' sometimes producing wrong results.
AFAICT IEEE , 'C' or 'C++' don't let you round to 'places',
hello @all, hello @Steve,
> I don't understand what you mean by "crossover",
=rounddown(0,24997;16) -> 0,25000, and
=roundup(0,24997;16) -> 0,249972244, the operation named 'down' going 'up', you commented about that about 2 weeks ago,
>
hello @all, hello @Steve,
tried it myself, it works to a good extent, see attached sheet and code below, but it is probably not 'well fitted' into the style and manners of gnumeric. if someone could rework this it would be very kind.
what is it needed for? just one example, if you want to
hello @Steve,
> You should read these:
be assured: i did ... not all of them to the full extent, but most of them multiple times ... i do! have a understanding of fp-math,
> you can't understand why numeric calculations behave as they do,
be assured: i can differentiate 'behave as they
@John Denker ... :-) :-) :-)
took some time, but got it to work,
find below a sort of 'log', not accurate!, of my path through the 'not's' and 'other's' ... most will result from a 'newbie system' missing plenty of options / packets usually present on profi systems ...
was challenging and fun
hello list,
this is a follow up to a question mailed some days ago,
i have some problems with rounding in gnumeric, tried to make a sheet which shows them in detail, see attachement,
in short: roundup and rounddown act irregularly with some values, i'd consider it important to fix that as
hello @aguelzow, thanks for the quick reply,
that explains rounding 0.3000444 as the binary midpoint between 0.2999889 and 0.3000999 to the bigger value (tie to even, away from zero, bankers rounding or whatever),
but - sorry if i insist -,
81 matches
Mail list logo
