Comments and discussion on Valentin's 4th "Then and Now" - Area

[Valentin Albillo]

.

Hi, J-F,

(01-19-2023 09:23 PM)J-F Garnier Wrote:  First of all, thanks to Valentin for this new problem. It kept me busy for long hours.

You're welcome. Glad you liked it.

Quote:Also the kind request to postpone our results for a few days was an interesting exercise.

Not everyone agreed. Someone posted his solution before the stated time limit, which I'm sure you didn't like at all, though I immediately posted a message to let the person know and he kindly deleted the post.

Also, some other person essentially complained that he much preferred to see tentative post after tentative post, refining the solution all the time, and learning from the refining process, which with the delay and the suggestion (not mandatory rule) that people would do best refining their initial solutions before posting them, to reduce the clutter in the thread, essentially prevented that learning process for him.

This being so, I'm not sure if the benefits outdo the disadvantages, so perhaps I will reinstate the 2-3 day delay for future problems, or perhaps I won't. What do you think ?

Quote:1. You may wonder why Valentin explicitly declared the variable U ("DIM U"), and not the others. Don't remove this DIM statement! Its purpose is related to a HP-71B bug, still present in the latest 2CDCC version and documented here, that I can summarize as: don't create new variables in the functions called by INTEGRAL or FNROOT, but create/declare them before.

Correct. I mentioned it in my original solution's post, I quote:

"Line 1: [...] DIM U is necessary to create variable U here and not inside DEF FNW, where we would fall prey to a well-known system bug."

Quote:The "1/10^10" expression may look inefficient and be better replaced by 1E-10.
The problem is that the HP-71 decompiles this value in standard format as .0000000001 that is difficult to re-read.

Correct. On the positive side, though entering 1E-10 is decompiled as .0000000001 (which certainly looks ungainly and may cause the line to exceed maximum length,) it has the benefit that it takes 4 less bytes of RAM (my program would get shortened from 244 bytes to just 240 bytes,) and also executes somewhat faster.

Albert Chan Wrote:I had already spent my 1 post in VA thread.

Let's see. First of all, you posted 3 times to the thread, not 1, which is perfectly Ok by me, and in any case I posted the following:

"Wait instead until next Wednesday 9:00 pm GMT+1 so that other people will have a chance. In the meantime you can mull it over so that you eventually post the one (1) message featuring your fully refined solution instead of a myriad posts refining it little by little."

but it's just a suggestion, not a mandatory rule, so you hadn't already spent anything, you could have posted again, no problem there. On the other hand, you're one of the "usual suspects" that tend to post the aforequoted "myriad" posts with marginal improvements (which at times, aren't) instead of thinking it over and suitably refining your approach before posting it. I can cite many threads where you've done exactly that, for no good reason that I can discern other that you seem to be itching to do it.

Don't take my advice if you don't want to and please don't take offence, but I think that your efforts and time would be best spent creting a very good, refined post, properly formatted, for the benefit of the readers if nothing else.

Also, in your code above, namely:

10 DESTROY ALL @ M=30.07 @ A=.831971149978 @ B=2.82740261413-A @ P=10^(-8)
20 T=1/3 @ DEF FND(Y,S)=SGN(Y+S)*ABS(Y+S)^T-SGN(Y-S)*ABS(Y-S)^T
[...]
60 DISP INTEGRAL(-4.08514674762,-4.04921226445.P,FNF(IVAR));"=";I+RES,TIME"

you are using four full-accuracy values that come out of nowhere, the program does not compute them in any way, not even refining d.dd approximations as suggested in my OP. You just stuck the numbers there, and any user looking at your code later wouldn't have the slightest idea of the origin of those values. Your program gets them out of the blue.

Last, in one of your posts in my main thread you begin your post with this, I quote:

"exp(-((x-d)^3-y)^2) > (R = y^2/M + exp(-sin(y)))      // Given: M=30.07, d=1.596

Let s = sqrt(-log(R)) ≥ 0

((x-d)^3-y)^2 < s^2
y-s < (x-d)^3 < y+s

x is real if s is real --> R ≤ 1 --> 0 ≤ y ≤ 2.82740261413

Height, \(\displaystyle f(y) = x_2 - x_1 = \sqrt[3]{y+s} - \sqrt[3]{y-s}\)

f slope is infinite when y = s --> R = exp(-y^2) --> y = 0 or 0.831971149978

Let a = 0.831971149978, a+b = a+B/2= 2.82740261413"

where you use variables b and B/2, but up to that point you haven't defined them nor assigned any value to them since the beginning of the post, so once again they come out of the blue. IMHO, you shouldn't do that, i.e., using variables before you define them and/or before assigning values to them, it's bad practice and likely to confuse the reader.

My honest, well-meaning advice would be: Do not be so eager to spend your time posting message after message, instead do try to refine your solution before posting anything, also don't include constants out of the blue, and last but certainly not least, spend a decent amount of time properly formatting your explanations and improving the understandability of your expressions.

Remember, the quality of your posts ultimately depends not only on the quality of your math but equally important, also depends on the quality of the presentation of your results.

Hope it helps. Thanks for your interest in my challenges ("Problems") and for your valuable contributions.

Regards.
V.