Expression Type Function Additions and Nested Mixed Unit Array Unit Operations

[StuartBruff]

TBD - finger trouble.

[Werner_E]

---

@StuartBruff wrote:

TBD - finger trouble.

---

TBD ???

You use "complex" not in the mathematical meaning (complex numbers include the reals) but rather in the sense of "non-real while still a number".

Or is this the reason you withdrew the file?

Not sure about IsImag vs IsComplex ??

Or is IsImag supposed to test for 'pure' imaginary numbers?

I recall two definitions for them.

The first one defines them as the product of a real number and the imaginary unit. Using this definition, zero must be considered pure imaginary.

A second definition states that it is a number whose square is a negative real number. According to this definition, zero would not be included.

A third definition (yes, its the third of the two I recall) is similar to the second but uses "non-positive" instead of "negative" and so is equivalent to the first one.

Even if it looks strange on first sight that the 'normal' number zero should be pure imaginary, but nonetheless there is a logic in the first (and third) definition as it includes all points (including zero) in the Gauß plane lying on the imaginary axis.

And thats exactly what your IsImag is checking for. The description has to be modified as it was obviously copied from IsReal and is partially not changed to fit the new function.

So you may have 0 included in your IsComplex on purpose? I'm still struggling with the name, since every real number is automatically a complex number.

[StuartBruff]

Yes, major finger trouble. Starting at the distant end of the finger’s nerves. I believe it’s called the “brain” in humans. Not sure what mine’s called. 😕

I was a bit sleepy when I “completed“ the worksheet and, idiot that I am, decided to post it whilst nodding off over the keyboard. Consequently, I didn’t notice that I was looking at a slightly earlier version of the worksheet or that the units functions weren’t showing the correct results (I’d been playing with an alternative, unsuccessful method of recursion). 

And, of course, the “earlier” version turned out to be the latest version because I’d accidentally not saved the “correct “ version.  A truly bad hair day, as they say. Shortly after posting the topic, I was fast asleep with my fingers still on the keyboard, and stayed that way for a couple of hours.

Not only did the posted worksheet not work, it didn’t include my further observations on the incomplete support for ranges. In particular, and this has been a long standing annoyance, one can’t get at the elements of a range … ISTR you could do this in M11 using the symbolic undocumented function ops(?).

Anyway, although you can assign units to a range (subject to it being defined as a 3-part range) and SIUnitsOf will tell you what those (SI) units are you can’t divide a range rng by SIUnitOf(rng). The only workaround I know of is to convert the range to a vector, and then reconstruct the range … which can be computationally expensive for “large” ranges. And I needed this for UnitsOf and removeUnits.

While I’m on the topic of ranges, another shortcoming is the lack of support for string ranges, ie “a”,”c”..”k”. Yes, it requires a bit of thought about how to interpret them (eg, “a”..”zz”) but it can be done (eg, look at last letter of the end string (”z”) and use the characters in “a”..”z” as the basis for the sequence. Ask me how I know).  

Oh, and simple arithmetic operations on ranges. That would make it far easier to scale integer ranges and to generate a matching “index” range for non-integral ranges. That would help with a lot of the problems people have with ranges. Still, as usual, I digress. I’m reconstructing the correct and missing parts of the worksheet and abnormal service will be resumed shortly.

As I’m dropping off over my artisanal, strength 7 coffee, I suppose I’d better go to bed and put on an audiobook I want to listen to, before I do too much further damage.  Nothing better guaranteed to send me to sleep.!  If I want to stay awake, I listen to one that is boring me to tears with its tediousness.

Thanks for the comments. I shall read them when sufficiently restored.

Stuart

[LucMeekes]

This is what I've been working on over the past few week. Needless to say, all IsSomething functions work (if they work.... see the functions response on a range argument) in Prime express (v4 file attached). Thanks for the IsNested, Stuart!

I'm quite fond of IsPrime, and a native IsRange is dearly missed.

Luc

[StuartBruff]

Apologies for not responding sooner, Luc.   I've stolen your IsPrime function for my soon-to-be-reissued Expression Type Functions worksheet.  Very neat.  I thought I might have been able to speed it up a few clock cycles by seeding it with the primes up to 37, but it actually slowed it down.

I did manage to squeeze a couple more primes out of the top end, though.

Stuart

[LucMeekes]

You're welcome. It's through collaboration that we get to better solutions.

I deliberately limited the top end of the Primes, because the correct representation of genuine integers in the floating point implementation has an upper limit.

Luc

[StuartBruff]

Indeed it is through collaboration that we gain more than the sum of the parts.  It’s one reason I liked the Mathsoft forum's name - the Collaboratory.

As with most IEEE 64-bit double floating-point systems, the maximum safe integer value is 2⁵³ or 2⁵³-1.   I've used this value since Mathcad 11 days.  However, the numerical evaluation of this number isn't necessarily accurate.  As you say, there appears to be a number of digits problem.   I checked it again recently, as I decided to take a take a fresh look at Gaussian integers and other integral number systems.

maxint and maxint-1 do not equate to each other, but they evaluate the same.

In addition, Mathcad seems to think anything outside the range -2³¹..2³¹-1 isn't a member of the set of integers.

Stuart

[StuartBruff]

---

---

---

@Werner_E wrote:

---

@StuartBruff wrote:

TBD - finger trouble.

---

TBD ???

---

I hoped to have an updated Expression Type Functions worksheet ready by now, but I've been chatting with PTC about the problem of NaNs gaining unwanted units.  As my revised SIUnitsOf, SIValueOf, HasUnits, and ApplyUnits are not particularly Boolean in nature, I've decided to cut them out of the Expression Type worksheet and give them a brand new home.   So, I hope to post an new Expression Type Functions worksheet in a couple of days (see, there's my unbridled optimism shining through again! 😁)

---

You use "complex" not in the mathematical meaning (complex numbers include the reals) but rather in the sense of "non-real while still a number".

Or is this the reason you withdrew the file?

Not sure about IsImag vs IsComplex ??

Or is IsImag supposed to test for 'pure' imaginary numbers?

I recall two definitions for them.

The first one defines them as the product of a real number and the imaginary unit. Using this definition, zero must be considered pure imaginary.

A second definition states that it is a number whose square is a negative real number. According to this definition, zero would not be included.

A third definition (yes, its the third of the two I recall) is similar to the second but uses "non-positive" instead of "negative" and so is equivalent to the first one.

Even if it looks strange on first sight that the 'normal' number zero should be pure imaginary, but nonetheless there is a logic in the first (and third) definition as it includes all points (including zero) in the Gauß plane lying on the imaginary axis.

And thats exactly what your IsImag is checking for. The description has to be modified as it was obviously copied from IsReal and is partially not changed to fit the new function.

So you may have 0 included in your IsComplex on purpose? I'm still struggling with the name, since every real number is automatically a complex number.

---

Oh, if one wishes to keep oneself entertained there are many different definitions of what complex numbers are.   Not all of them implicitly regard real numbers as being identical to the real part of complex numbers, albeit that is how they are usually interpreted (particularly as complex numbers are a extension of the reals).

I haven't seen the second interpretation in print, but it makes more sense to me than adding the imaginary part whilst assuming (or defining) the real part to be the real number line.   I also find the very recursive nature of defining real numbers in terms of themselves raises some misgivings on my part (and I certainly don't have a problem with recursion!).

So, back to your questions.  Yes, IsImag is meant to test for purely imaginary numbers - they do not behave the same as purely real numbers.  IsComplex was a means of identifying complex numbers so that I'd know how to deal with them on specific occasions; ranges, for example, can be real but not complex (although I see no a priori reason why they shouldn't be).  Neither IsImag nor IsReal alone is sufficient unto the task; zero is right at the intersection of the real and imaginary parts, hence its inclusion in IsComplex.  Furthermore, reals would possess no additive identity if zero was not a real number, nor would the reals possess additive inverses.

However, part of the reason for posting such worksheets is to garner the opinions of others, not to enforce my viewpoint, and I'm perfectly willing to change my mind if threatened or bribed sufficiently.

Stuart

(I also posted the attached worksheet in the recent vec function thread)