Related
When we have repeated measurements on an experimental unit, typically these units cannot be considered 'independent' and need to be modeled in a way that we get valid estimates for our standard errors.
When I compare the intervals obtained by computing the marginal means for the treatment using a mixed model (treating the unit as a random effect) and in the other case, first averaging over the unit and THEN runnning a simple linear model on the averaged responses, I get the exact same uncertainty intervals.
How do we incorporate the uncertainty of the measurements of the unit, into the uncertainty of what we think our treatments look like?
In order to really propogate all the uncertainty, shouldn't we see what the treatment looks like, averaged over "all possible measurements" on a unit?
``` r
library(dplyr)
#>
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#>
#> filter, lag
#> The following objects are masked from 'package:base':
#>
#> intersect, setdiff, setequal, union
library(emmeans)
library(lme4)
#> Loading required package: Matrix
library(ggplot2)
tmp <- structure(list(treatment = c("A", "A", "A", "A", "A", "A", "A",
"A", "A", "A", "A", "A", "B", "B", "B", "B", "B", "B", "B", "B",
"B", "B", "B", "B"), response = c(151.27333548, 162.3933313,
159.2199999, 159.16666725, 210.82, 204.18666667, 196.97333333,
194.54666667, 154.18666667, 194.99333333, 193.48, 191.71333333,
124.1, 109.32666667, 105.32, 102.22, 110.83333333, 114.66666667,
110.54, 107.82, 105.62000069, 79.79999821, 77.58666557, 75.78666928
), experimental_unit = c("A-1", "A-1", "A-1", "A-1", "A-2", "A-2",
"A-2", "A-2", "A-3", "A-3", "A-3", "A-3", "B-1", "B-1", "B-1",
"B-1", "B-2", "B-2", "B-2", "B-2", "B-3", "B-3", "B-3", "B-3"
)), row.names = c(NA, -24L), class = c("tbl_df", "tbl", "data.frame"
))
### Option 1 - Treat the experimental unit as a random effect since there are
### 4 repeat observations for the same unit
lme4::lmer(response ~ treatment + (1 | experimental_unit), data = tmp) %>%
emmeans::emmeans(., ~ treatment) %>%
as.data.frame()
#> treatment emmean SE df lower.CL upper.CL
#> 1 A 181.0794 10.83359 4 151.00058 211.1583
#> 2 B 101.9683 10.83359 4 71.88947 132.0472
#ggplot(.,aes(treatment, emmean)) +
#geom_pointrange(aes(ymin = lower.CL, ymax = upper.CL))
### Option 2 - instead of treating the unit as random effect, we average over the
### 4 repeat observations, and run a simple linear model
tmp %>%
group_by(experimental_unit) %>%
summarise(mean_response = mean(response)) %>%
mutate(treatment = c(rep("A", 3), rep("B", 3))) %>%
lm(mean_response ~ treatment, data = .) %>%
emmeans::emmeans(., ~ treatment) %>%
as.data.frame()
#> treatment emmean SE df lower.CL upper.CL
#> 1 A 181.0794 10.83359 4 151.00058 211.1583
#> 2 B 101.9683 10.83359 4 71.88947 132.0472
#ggplot(., aes(treatment, emmean)) +
#geom_pointrange(aes(ymin = lower.CL, ymax = upper.CL))
### Whether we include a random effect for the unit, or average over it and THEN model it, we find no difference in the
### marginal means for the treatments
### How do we incoporate the variation of the repeat measurments to the marginal means of the treatments?
### Do we then ignore the variation in the 'subsamples' and simply average over them PRIOR to modeling?
<sup>Created on 2021-07-31 by the [reprex package](https://reprex.tidyverse.org) (v2.0.0)</sup>
emmeans() does take into account the errors of random effects. This is what I get when I remove the complex sequences of pipes:
> mmod = lme4::lmer(response ~ treatment + (1 | experimental_unit), data = tmp)
> emmeans(mmod, "treatment")
treatment emmean SE df lower.CL upper.CL
A 181 10.8 4 151.0 211
B 102 10.8 4 71.9 132
Degrees-of-freedom method: kenward-roger
Confidence level used: 0.95
This is as shown. If I fit a fixed-effects model that accounts for experimental units as a fixed effect, I get:
> fmod = lm(response ~ treatment + experimental_unit, data = tmp)
> emmeans(fmod, "treatment")
NOTE: A nesting structure was detected in the fitted model:
experimental_unit %in% treatment
treatment emmean SE df lower.CL upper.CL
A 181 3.25 18 174.2 188
B 102 3.25 18 95.1 109
Results are averaged over the levels of: experimental_unit
Confidence level used: 0.95
The SEs of the latter results are considerably lower, and that is because the random variations in experimental_unit are modeled as fixed variations.
Apparently the piping you did accounts for the variation of the random effects and includes those in the EMMs. I think that is because you did things separately for each experimental unit and somehow combined those results. I'm not very comfortable with a sequence of pipes that is 7 steps long, and I don't understand why that results in just one set of means.
I recommend against the as.data.frame() at the end. That zaps out annotations that can be helpful in understanding what you have. If you are doing that to get more digits precision, I'll claim that those are digits you don't need, it just exaggerates the precision you are entitled to claim.
Notes on some follow-up comments
Subsequently, I am convinced that what we see in the piped operations in the second part of the OP doe indeed comprise computing the mean of each EU, then analyzing those.
Let's look at that in the context of the formal model. We have (sorry MathJax doesn't work on stackoverflow, but I'll leave the markup there anyway)
$$ Y_{ijk} = \mu + \tau_i + U_{ij} + E_{ijk} $$
where $Y_{ijk}$ is the kth response measurement on the ith treatment and jth EU in the ith treatment, and the rhs terms represent respectively the overall mean, the (fixed) treatment effects, the (random) EU effects, and the (random) error effects. We assume the random effects are all mutually independent. With a balanced design, the EMMs are just the marginal means:
$$ \bar Y_{i..} = \mu + \tau_i + \bar U_{i.} + \bar E_{i..} $$
where a '.' subscript means we averaged over that subscript. If there are n EUs per treatment and m measurements on each EU, we get that
$$ Var(\bar Y_{i..} = \sigma^2_U / n + \sigma^2_E / mn $$
Now, if we aggregate the data on EUs ahead of time, we are starting with
$$ \bar Y_{ij.} = \mu + U_{ij} + \bar E_{ij.} $$
However, if we then compute marginal means by averaging over j, we get exactly the same thing as we did before with $\bar Y_{i..}$, and the variance is exactly as already shown. That is why it doesn't matter if we aggregated first or not.
I'm fiddling with DNSSEC, and I'd like to try to verify NSEC3 records generated by dnssec-signzone from bind9-utils (which I presume are valid). This is my zone file:
$ORIGIN dnssectest.mvolfik.tk.
$TTL 120
# SOA dnssectestns.mvolfik.tk. email.example.com. 15 259200 3600 300000 3600
A 192.168.0.101
s3c A 192.168.0.101
$INCLUDE zsk.key
$INCLUDE ksk.key
ZSK and KSK are generated with dnssec-keygen -a ECDSAP256SHA256 dnssectest.mvolfik.tk. (add -f KSK respectively)
I then signed it using the command dnssec-signzone -3 deadbeef -H 5 -o dnssectest.mvolfik.tk -k ksk.key zonefile zsk.key (use NSEC3 with deadbeef hex salt, 5 iterations)
I got the following NSEC3 records in the zonefile.signed: (omitted RRSIG and DNSKEY as irrelevant; A and SOA didn't change)
0 NSEC3PARAM 1 0 5 DEADBEEF
F66KKS17FM851AVA4EARFHS55I3TOO85.dnssectest.mvolfik.tk. 3600 IN NSEC3 1 0 5 DEADBEEF (
D60TA5J5RS4JD5AQK25B1BCUAHGP4DHC
A SOA RRSIG DNSKEY NSEC3PARAM )
D60TA5J5RS4JD5AQK25B1BCUAHGP4DHC.dnssectest.mvolfik.tk. 3600 IN NSEC3 1 0 5 DEADBEEF (
F66KKS17FM851AVA4EARFHS55I3TOO85
A RRSIG )
Now that I know that the only domains in this zone are s3c.dnssectest.mvolfik.tk. and dnssectest.mvolfik.tk., I assume that the following Python script would get me the same hashes as in the signe zone file above: (from pseudocode in RFC 5155)
import hashlib
def ih(salt, x, k):
if k == 0:
return hashlib.sha1(x + salt).digest()
return hashlib.sha1(ih(salt, x, k-1) + salt).digest()
print(ih(bytes.fromhex("deadbeef"), b"s3c.dnssectest.mvolfik.tk.", 5).hex())
print(ih(bytes.fromhex("deadbeef"), b"dnssectest.mvolfik.tk.", 5).hex())
However, I instead got b58374998347ba833ab33f15332829a589a80d82 and 545e01397a776ee73aa0372aea015408cc384574. What am I doing wrong?
So I looked into dnspython source code, and found the nsec3_hash function. Turns out that the name must be in wire format (means removing dots and instead prefixing labels a length byte - \x03s3c\x10dnssectest\x07mvolfik\x02tk\x00 etc, null byte at the end). And the result is encoded with base32 (0-9A-V), not hex. Probably easier just to use the dnspython library, but here's the full (a bit naive) code:
import hashlib, base64
b32_trans = str.maketrans(
"ABCDEFGHIJKLMNOPQRSTUVWXYZ234567", "0123456789ABCDEFGHIJKLMNOPQRSTUV"
)
def ih(salt, x, k):
if k == 0:
return hashlib.sha1(x + salt).digest()
return hashlib.sha1(ih(salt, x, k - 1) + salt).digest()
def nsec3(salt, name, k):
if not name.endswith("."):
name += "."
labels = name.split(".")
name_wire = b"".join(len(l).to_bytes(1, "big") + l.lower().encode() for l in labels)
digest = ih(bytes.fromhex(salt), name_wire, k)
return base64.b32encode(digest).decode().translate(b32_trans)
print(nsec3("deadbeef", "dnssectest.mvolfik.tk.", 5))
print(nsec3("deadbeef", "s3c.dnssectest.mvolfik.tk.", 5))
This gets the correct hashes seen in the NSEC3 records
Spotify Codes are little barcodes that allow you to share songs, artists, users, playlists, etc.
They encode information in the different heights of the "bars". There are 8 discrete heights that the 23 bars can be, which means 8^23 different possible barcodes.
Spotify generates barcodes based on their URI schema. This URI spotify:playlist:37i9dQZF1DXcBWIGoYBM5M gets mapped to this barcode:
The URI has a lot more information (62^22) in it than the code. How would you map the URI to the barcode? It seems like you can't simply encode the URI directly. For more background, see my "answer" to this question: https://stackoverflow.com/a/62120952/10703868
The patent explains the general process, this is what I have found.
This is a more recent patent
When using the Spotify code generator the website makes a request to https://scannables.scdn.co/uri/plain/[format]/[background-color-in-hex]/[code-color-in-text]/[size]/[spotify-URI].
Using Burp Suite, when scanning a code through Spotify the app sends a request to Spotify's API: https://spclient.wg.spotify.com/scannable-id/id/[CODE]?format=json where [CODE] is the media reference that you were looking for. This request can be made through python but only with the [TOKEN] that was generated through the app as this is the only way to get the correct scope. The app token expires in about half an hour.
import requests
head={
"X-Client-Id": "58bd3c95768941ea9eb4350aaa033eb3",
"Accept-Encoding": "gzip, deflate",
"Connection": "close",
"App-Platform": "iOS",
"Accept": "*/*",
"User-Agent": "Spotify/8.5.68 iOS/13.4 (iPhone9,3)",
"Accept-Language": "en",
"Authorization": "Bearer [TOKEN]",
"Spotify-App-Version": "8.5.68"}
response = requests.get('https://spclient.wg.spotify.com:443/scannable-id/id/26560102031?format=json', headers=head)
print(response)
print(response.json())
Which returns:
<Response [200]>
{'target': 'spotify:playlist:37i9dQZF1DXcBWIGoYBM5M'}
So 26560102031 is the media reference for your playlist.
The patent states that the code is first detected and then possibly converted into 63 bits using a Gray table. For example 361354354471425226605 is encoded into 010 101 001 010 111 110 010 111 110 110 100 001 110 011 111 011 011 101 101 000 111.
However the code sent to the API is 6875667268, I'm unsure how the media reference is generated but this is the number used in the lookup table.
The reference contains the integers 0-9 compared to the gray table of 0-7 implying that an algorithm using normal binary has been used. The patent talks about using a convolutional code and then the Viterbi algorithm for error correction, so this may be the output from that. Something that is impossible to recreate whithout the states I believe. However I'd be interested if you can interpret the patent any better.
This media reference is 10 digits however others have 11 or 12.
Here are two more examples of the raw distances, the gray table binary and then the media reference:
1.
022673352171662032460
000 011 011 101 100 010 010 111 011 001 100 001 101 101 011 000 010 011 110 101 000
67775490487
2.
574146602473467556050
111 100 110 001 110 101 101 000 011 110 100 010 110 101 100 111 111 101 000 111 000
57639171874
edit:
Some extra info:
There are some posts online describing how you can encode any text such as spotify:playlist:HelloWorld into a code however this no longer works.
I also discovered through the proxy that you can use the domain to fetch the album art of a track above the code. This suggests a closer integration of Spotify's API and this scannables url than previously thought. As it not only stores the URIs and their codes but can also validate URIs and return updated album art.
https://scannables.scdn.co/uri/800/spotify%3Atrack%3A0J8oh5MAMyUPRIgflnjwmB
Your suspicion was correct - they're using a lookup table. For all of the fun technical details, the relevant patent is available here: https://data.epo.org/publication-server/rest/v1.0/publication-dates/20190220/patents/EP3444755NWA1/document.pdf
Very interesting discussion. Always been attracted to barcodes so I had to take a look. I did some analysis of the barcodes alone (didn't access the API for the media refs) and think I have the basic encoding process figured out. However, based on the two examples above, I'm not convinced I have the mapping from media ref to 37-bit vector correct (i.e. it works in case 2 but not case 1). At any rate, if you have a few more pairs, that last part should be simple to work out. Let me know.
For those who want to figure this out, don't read the spoilers below!
It turns out that the basic process outlined in the patent is correct, but lacking in details. I'll summarize below using the example above. I actually analyzed this in reverse which is why I think the code description is basically correct except for step (1), i.e. I generated 45 barcodes and all of them matched had this code.
1. Map the media reference as integer to 37 bit vector.
Something like write number in base 2, with lowest significant bit
on the left and zero-padding on right if necessary.
57639171874 -> 0100010011101111111100011101011010110
2. Calculate CRC-8-CCITT, i.e. generator x^8 + x^2 + x + 1
The following steps are needed to calculate the 8 CRC bits:
Pad with 3 bits on the right:
01000100 11101111 11110001 11010110 10110000
Reverse bytes:
00100010 11110111 10001111 01101011 00001101
Calculate CRC as normal (highest order degree on the left):
-> 11001100
Reverse CRC:
-> 00110011
Invert check:
-> 11001100
Finally append to step 1 result:
01000100 11101111 11110001 11010110 10110110 01100
3. Convolutionally encode the 45 bits using the common generator
polynomials (1011011, 1111001) in binary with puncture pattern
110110 (or 101, 110 on each stream). The result of step 2 is
encoded using tail-biting, meaning we begin the shift register
in the state of the last 6 bits of the 45 long input vector.
Prepend stream with last 6 bits of data:
001100 01000100 11101111 11110001 11010110 10110110 01100
Encode using first generator:
(a) 100011100111110100110011110100000010001001011
Encode using 2nd generator:
(b) 110011100010110110110100101101011100110011011
Interleave bits (abab...):
11010000111111000010111011110011010011110001...
1010111001110001000101011000010110000111001111
Puncture every third bit:
111000111100101111101110111001011100110000100100011100110011
4. Permute data by choosing indices 0, 7, 14, 21, 28, 35, 42, 49,
56, 3, 10..., i.e. incrementing 7 modulo 60. (Note: unpermute by
incrementing 43 mod 60).
The encoded sequence after permuting is
111100110001110101101000011110010110101100111111101000111000
5. The final step is to map back to bar lengths 0 to 7 using the
gray map (000,001,011,010,110,111,101,100). This gives the 20 bar
encoding. As noted before, add three bars: short one on each end
and a long one in the middle.
UPDATE: I've added a barcode (levels) decoder (assuming no errors) and an alternate encoder that follows the description above rather than the equivalent linear algebra method. Hopefully that is a bit more clear.
UPDATE 2: Got rid of most of the hard-coded arrays to illustrate how they are generated.
The linear algebra method defines the linear transformation (spotify_generator) and mask to map the 37 bit input into the 60 bit convolutionally encoded data. The mask is result of the 8-bit inverted CRC being convolutionally encoded. The spotify_generator is a 37x60 matrix that implements the product of generators for the CRC (a 37x45 matrix) and convolutional codes (a 45x60 matrix). You can create the generator matrix from an encoding function by applying the function to each row of an appropriate size generator matrix. For example, a CRC function that add 8 bits to each 37 bit data vector applied to each row of a 37x37 identity matrix.
import numpy as np
import crccheck
# Utils for conversion between int, array of binary
# and array of bytes (as ints)
def int_to_bin(num, length, endian):
if endian == 'l':
return [num >> i & 1 for i in range(0, length)]
elif endian == 'b':
return [num >> i & 1 for i in range(length-1, -1, -1)]
def bin_to_int(bin,length):
return int("".join([str(bin[i]) for i in range(length-1,-1,-1)]),2)
def bin_to_bytes(bin, length):
b = bin[0:length] + [0] * (-length % 8)
return [(b[i]<<7) + (b[i+1]<<6) + (b[i+2]<<5) + (b[i+3]<<4) +
(b[i+4]<<3) + (b[i+5]<<2) + (b[i+6]<<1) + b[i+7] for i in range(0,len(b),8)]
# Return the circular right shift of an array by 'n' positions
def shift_right(arr, n):
return arr[-n % len(arr):len(arr):] + arr[0:-n % len(arr)]
gray_code = [0,1,3,2,7,6,4,5]
gray_code_inv = [[0,0,0],[0,0,1],[0,1,1],[0,1,0],
[1,1,0],[1,1,1],[1,0,1],[1,0,0]]
# CRC using Rocksoft model:
# NOTE: this is not quite any of their predefined CRC's
# 8: number of check bits (degree of poly)
# 0x7: representation of poly without high term (x^8+x^2+x+1)
# 0x0: initial fill of register
# True: byte reverse data
# True: byte reverse check
# 0xff: Mask check (i.e. invert)
spotify_crc = crccheck.crc.Crc(8, 0x7, 0x0, True, True, 0xff)
def calc_spotify_crc(bin37):
bytes = bin_to_bytes(bin37, 37)
return int_to_bin(spotify_crc.calc(bytes), 8, 'b')
def check_spotify_crc(bin45):
data = bin_to_bytes(bin45,37)
return spotify_crc.calc(data) == bin_to_bytes(bin45[37:], 8)[0]
# Simple convolutional encoder
def encode_cc(dat):
gen1 = [1,0,1,1,0,1,1]
gen2 = [1,1,1,1,0,0,1]
punct = [1,1,0]
dat_pad = dat[-6:] + dat # 6 bits are needed to initialize
# register for tail-biting
stream1 = np.convolve(dat_pad, gen1, mode='valid') % 2
stream2 = np.convolve(dat_pad, gen2, mode='valid') % 2
enc = [val for pair in zip(stream1, stream2) for val in pair]
return [enc[i] for i in range(len(enc)) if punct[i % 3]]
# To create a generator matrix for a code, we encode each row
# of the identity matrix. Note that the CRC is not quite linear
# because of the check mask so we apply the lamda function to
# invert it. Given a 37 bit media reference we can encode by
# ref * spotify_generator + spotify_mask (mod 2)
_i37 = np.identity(37, dtype=bool)
crc_generator = [_i37[r].tolist() +
list(map(lambda x : 1-x, calc_spotify_crc(_i37[r].tolist())))
for r in range(37)]
spotify_generator = 1*np.array([encode_cc(crc_generator[r]) for r in range(37)], dtype=bool)
del _i37
spotify_mask = 1*np.array(encode_cc(37*[0] + 8*[1]), dtype=bool)
# The following matrix is used to "invert" the convolutional code.
# In particular, we choose a 45 vector basis for the columns of the
# generator matrix (by deleting those in positions equal to 2 mod 4)
# and then inverting the matrix. By selecting the corresponding 45
# elements of the convolutionally encoded vector and multiplying
# on the right by this matrix, we get back to the unencoded data,
# assuming there are no errors.
# Note: numpy does not invert binary matrices, i.e. GF(2), so we
# hard code the following 3 row vectors to generate the matrix.
conv_gen = [[0,1,0,1,1,1,1,0,1,1,0,0,0,1]+31*[0],
[1,0,1,0,1,0,1,0,0,0,1,1,1] + 32*[0],
[0,0,1,0,1,1,1,1,1,1,0,0,1] + 32*[0] ]
conv_generator_inv = 1*np.array([shift_right(conv_gen[(s-27) % 3],s) for s in range(27,72)], dtype=bool)
# Given an integer media reference, returns list of 20 barcode levels
def spotify_bar_code(ref):
bin37 = np.array([int_to_bin(ref, 37, 'l')], dtype=bool)
enc = (np.add(1*np.dot(bin37, spotify_generator), spotify_mask) % 2).flatten()
perm = [enc[7*i % 60] for i in range(60)]
return [gray_code[4*perm[i]+2*perm[i+1]+perm[i+2]] for i in range(0,len(perm),3)]
# Equivalent function but using CRC and CC encoders.
def spotify_bar_code2(ref):
bin37 = int_to_bin(ref, 37, 'l')
enc_crc = bin37 + calc_spotify_crc(bin37)
enc_cc = encode_cc(enc_crc)
perm = [enc_cc[7*i % 60] for i in range(60)]
return [gray_code[4*perm[i]+2*perm[i+1]+perm[i+2]] for i in range(0,len(perm),3)]
# Given 20 (clean) barcode levels, returns media reference
def spotify_bar_decode(levels):
level_bits = np.array([gray_code_inv[levels[i]] for i in range(20)], dtype=bool).flatten()
conv_bits = [level_bits[43*i % 60] for i in range(60)]
cols = [i for i in range(60) if i % 4 != 2] # columns to invert
conv_bits45 = np.array([conv_bits[c] for c in cols], dtype=bool)
bin45 = (1*np.dot(conv_bits45, conv_generator_inv) % 2).tolist()
if check_spotify_crc(bin45):
return bin_to_int(bin45, 37)
else:
print('Error in levels; Use real decoder!!!')
return -1
And example:
>>> levels = [5,7,4,1,4,6,6,0,2,4,3,4,6,7,5,5,6,0,5,0]
>>> spotify_bar_decode(levels)
57639171874
>>> spotify_barcode(57639171874)
[5, 7, 4, 1, 4, 6, 6, 0, 2, 4, 3, 4, 6, 7, 5, 5, 6, 0, 5, 0]
everyone,
I'm trying to do some calculations and plot the results, but it seems that these are too heavy for Maxima. When I try to calculate N1 and N2 the program crashes when parameter j is too high or when I try to plot them, the program displays the following error message: "Heap exhausted, game over." What should I do? I've seen some people saying to try to compile Maxima with ccl, but I don't know how to do it or if it will work.
I usually receive error messages like:
Message from maxima's stderr stream: Heap exhausted during garbage collection: 0 bytes available, 16 requested.
Gen Boxed Unboxed LgBox LgUnbox Pin Alloc Waste Trig WP GCs Mem-age
0 0 0 0 0 0 0 0 20971520 0 0 0,0000
1 0 0 0 0 0 0 0 20971520 0 0 0,0000
2 0 0 0 0 0 0 0 20971520 0 0 0,0000
3 16417 2 0 0 43 1075328496 707088 293986768 16419 1 0,8032
4 13432 21 0 1141 70 955593760 838624 2000000 14594 0 0,2673
5 0 0 0 0 0 0 0 2000000 0 0 0,0000
6 741 184 34 28 0 63259792 1424240 2000000 987 0 0,0000
7 0 0 0 0 0 0 0 2000000 0 0 0,0000
Total bytes allocated = 2094182048
Dynamic-space-size bytes = 2097152000
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
*STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 13884(tid 0000000001236360):
Heap exhausted, game over.
Here goes the code:
enter code here
a: 80$;
b: 6*a$;
h1: 80$;
t: 2$;
j: 5$;
carga: 250$;
sig: -carga/2$;
n: 2*q*%pi/b$;
m: i*%pi/a$;
i: 2*p-1$;
i1: 2*p1-1$;
/*i1: p1$;*/
Φ: a/b$;
τ: cosh(x) - (x/sinh(x))$;
σ: sinh(x) - (x/cosh(x))$;
Ψ: sinh(x)/τ$;
Χ: cosh(x)/σ$;
Λ0: 1/(((i/2)^2+Φ^2*q^2)^2)$;
Λ1: sum((((i/2)^3*subst([x=(i*%pi/(2*Φ))],Ψ))/(((i/2)^2+Φ^2*q1^2)^2))*Λ0, p, 1, j)$;
Λ2: sum(((q1^3*subst([x=(q1*%pi*Φ)],Χ))/(((i/2)^2+Φ^2*q1^2)^2))*Λ1, q1, 1, j)$;
Λ3: sum((((i/2)^3*subst([x=(i*%pi/(2*Φ))],Ψ))/(((i/2)^2+Φ^2*q1^2)^2))*Λ2, p, 1, j)$;
Λ4: sum(((q1^3*subst([x=(q1*%pi*Φ)],Χ))/(((i/2)^2+Φ^2*q1^2)^2))*Λ3, q1, 1, j)$;
Λ5: sum((((i/2)^3*subst([x=(i*%pi/(2*Φ))],Ψ))/(((i/2)^2+Φ^2*q1^2)^2))*Λ4, p, 1, j)$;
Ζ0: sum(((q^3*subst([x=(q*%pi*Φ)],Χ))/(((i1/2)^2+Φ^2*q^2)^2))*Λ0, q, 1, j)$;
Ζ2: sum(((q^3*subst([x=(q*%pi*Φ)],Χ))/(((i1/2)^2+Φ^2*q^2)^2))*Λ2, q, 1, j)$;
Ζ4: sum(((q^3*subst([x=(q*%pi*Φ)],Χ))/(((i1/2)^2+Φ^2*q^2)^2))*Λ4, q, 1, j)$;
E: 200000$;
ν: 0.3$;
λ: (ν*E)/((1+ν)*(1-2*ν))$;
μ: E/(2*(1+ν))$;
a0: float(1/(b/2)*integrate(0, y, -(b/2), -h1/2)+1/b*integrate(sig, y, -h1/2, h1/2)+1/(b/2)*integrate(0, y, h1/2, (b/2)))$;
aq: float(1/(b/2)*integrate(0*cos(q*y*%pi/(b/2)), y, -(b/2), - h1/2)+1/(b/2)*integrate(sig*cos(q*y*%pi/(b/2)), y, -h1/2, h1/2)+1/(b/2)*integrate(0*cos(q*y*%pi/(b/2)), y, h1/2, (b/2)))$;
aq1: float(1/(b/2)*integrate(0*cos(q1*y*%pi/(b/2)), y, -(b/2), - h1/2)+1/(b/2)*integrate(sig*cos(q1*y*%pi/(b/2)), y, -h1/2, h1/2)+1/(b/2)*integrate(0*cos(q1*y*%pi/(b/2)), y, h1/2, (b/2)))$;
Bq: aq/((λ+μ)*subst([x=q*%pi*Φ],σ))+((16*Φ^4*q^2*(-1)^q)/((λ+μ)*%pi^2*subst([x=q*%pi*Φ],σ)))*sum(q1*aq1*(-1) ^q1*subst([x=q1*%pi*Φ],Χ)*(Λ1+(16*Φ^4/(%pi^2))*Λ3+((16*Φ^4/(%pi^2))^2)*Λ5), q1, 1, j)+(8*λ*Φ^3*q^2*(-1)^q*a0)/((λ+μ)*(λ+2*μ)*(%pi^3)*subst([x=q*%pi*Φ],σ))*sum(subst([x=i*%pi/(2*Φ)],Ψ)/(i/ 2)*(Λ0+(16*Φ^4/(%pi^2))*Λ2+((16*Φ^4/(%pi^2))^2)*Λ4), p, 1, j)$;
βp: -(2*λ*a0*(-1)^((i-1)/2))/((λ+μ)*(λ+2*μ)*(i/2)^2*%pi^2*subst([x=i*%pi/(2*Φ)],τ))-((32*λ*Φ^4*(i/2)^2*a0*(-1)^((i-1)/2))/((λ+μ)*(λ+2*μ)*%pi^2*subst([x=i*%pi/(2*Φ)],τ)))*sum(((subst([x=i1*%pi/(2*Φ)],Ψ))/(i1/2))*(Ζ0+Ζ2*((16*Φ^4)/%pi^2)+Ζ4*(((16*Φ^4)/%pi^2)^2)),p1,1,j)-((4*Φ*(i/2)^2*(-1)^((i-1)/2))/((λ+μ)*%pi*subst([x=i*%pi/(2*Φ)],τ)))*sum(q*aq*(-1)^q*subst([x=q*%pi*Φ],Χ)*(Λ0+Λ2*(16*Φ^4/%pi^2)+Λ4*(16*Φ^4/%pi^2)^2),q,1,j)$;
N1: (2*a0/a)*x+(λ+μ)*sum(Bq*((1+((n*a*sinh(n*a/2))/(2*cosh(n*a/2))))*sinh(n*x)-n*x*cosh(n*x))*cos(n*y),q,1,j)+(λ+μ)*sum(βp*((1-((m*b*cosh(m*b/2))/(2*sinh(m*b/2))))*cosh(m*y)+m*y*sinh(m*y))*sin(m*x),p,1,j)$;
N2: ((2*λ*a0)/(a*(λ+2*μ)))*x+(λ+μ)*sum(Bq*((1-((n*a*sinh(n*a/2))/(2*cosh(n*a/2))))*sinh(n*x)+n*x*cosh(n*x))*cos(n*y),q,1,j)+(λ+μ)*sum(βp*((1+((m*b*cosh(m*b/2))/(2*sinh(m*b/2))))*cosh(m*y)-m*y*sinh(m*y))*sin(m*x),p,1,j);
wxplot3d(N1, [x,-a/2,a/2], [y,-b/2,b/2])$;
wxplot3d(N2, [x,-a/2,a/2], [y,-b/2,b/2])$;
This is not a complete answer, since I don't know how this should work with wxMaxima: I would suggest that you ask the developers. However it's too long for a comment and I think might be useful to people, and it does answer the question of how you solve the heap-size limit for Maxima itself when using SBCL, at least when run on Linux or some other platform with a command-line.
As a note, I suspect that the underlying problem is not the heap size, but that the calculation is blowing up in some horrible way: the best fix is probably to understand what's blowing up and fix that. See Robert Dodier's answer, which is probably going to be a lot more helpful. However, if heap size is the problem, this is how you deal with it for Maxima.
The trick is that you can tell SBCL what the heap limit should be by passing it the --dynamic-space-size <MB> argument, and you can pas arguments through the maxima wrapper to do this.
Here is a transcript of Maxima, being run on Linux, with SBCL as a back end (this is a version built from source: the packaged version will I assume be the same):
$ maxima
Maxima 5.43.2 http://maxima.sourceforge.net
using Lisp SBCL 2.0.0
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) :lisp (sb-ext:dynamic-space-size)
1073741824
So, on this system the defaule heap limit is 1GB (this is SBCL's default limit on the platform).
Now we can pass the -X <lisp options> aka --lisp-options=<lisp options> option to the maxima wrapper to pass the appropriate option through to sbcl:
$ maxima -X '--dynamic-space-size 2000'
Lisp options: (--dynamic-space-size 2000)
Maxima 5.43.2 http://maxima.sourceforge.net
using Lisp SBCL 2.0.0
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) :lisp (sb-ext:dynamic-space-size)
2097152000
As you can see this has doubled the heap size.
If someone knows the answer for wxMaxima then please do add an edit to this answer: I can't experiment it because all my Linux VMs are headless.
Also not a complete answer here, but some more notes and pointers which I hope will help.
To make the problem easier for Maxima to digest, use only exact numbers (integers and ratios), and avoid float and numer. (Plotting functions will apply float and numer automatically.) I changed 0.3 to 3/10 and cut out the calls to float.
Also, try setting j to a smaller number (I tried j equal to 1) to try to work all the way through the problem before increasing it to 5 again.
Also, replace all sum and integrate with 'sum and 'integrate (i.e. noun expressions instead of verb expressions). Take a look at the summands and integrands to see if they look right. You can evaluate the sums and/or integrals or both via ev(expr, sum) or ev(expr, integrate) or ev(expr, nouns) to evaluate 'sum, 'integrate, or all noun expressions, respectively.
With j equal to 1, I get the following expression for N1:
(2500000*((-(13*cosh(%pi/6)
*((8503056*cosh(%pi/6)^2*sinh(3*%pi)^2)
/(9765625*%pi^4
*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))^2
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))^2)
+(52488*cosh(%pi/6)*sinh(3*%pi))
/(15625*%pi^2*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi)))
+324/25))
/(120000*%pi^2*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))))
+(13*sinh(3*%pi)
*((2754990144*cosh(%pi/6)^3*sinh(3*%pi)^2)
/(244140625*%pi^4
*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))^3
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))^2)
+(17006112*cosh(%pi/6)^2*sinh(3*%pi))
/(390625*%pi^2
*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))^2
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi)))
+(104976*cosh(%pi/6))
/(625*(sinh(%pi/6)-%pi/(6*cosh(%pi/6))))))
/(22680000*%pi^2*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))^2)
+13/(35000*%pi^2*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))))
*sin((%pi*(2*p-1)*x)/80)
*((%pi*(2*p-1)*y*sinh((%pi*(2*p-1)*y)/80))/80
+(1-(3*%pi*(2*p-1)*cosh(3*%pi*(2*p-1)))
/sinh(3*%pi*(2*p-1)))
*cosh((%pi*(2*p-1)*y)/80)))
/13
+(2500000*((-(13*cosh(%pi/6)
*((344373768*cosh(%pi/6)^2*sinh(3*%pi)^3)
/(244140625*%pi^4
*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))
^2
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))
^3)
+(2125764*cosh(%pi/6)*sinh(3*%pi)^2)
/(390625*%pi^2
*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))^2)
+(13122*sinh(3*%pi))
/(625*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi)))))
/(1620000*%pi^3*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))^2))
+(13*sinh(3*%pi)
*((8503056*cosh(%pi/6)^2*sinh(3*%pi)^2)
/(9765625*%pi^4
*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))^2
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi))^2)
+(52488*cosh(%pi/6)*sinh(3*%pi))
/(15625*%pi^2*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi)))
+324/25))
/(3780000*%pi^3*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))
*(cosh(3*%pi)-(3*%pi)/sinh(3*%pi)))
-13/(20000*%pi*(sinh(%pi/6)-%pi/(6*cosh(%pi/6)))))
*(((%pi*sinh(%pi/6))/(6*cosh(%pi/6))+1)
*sinh((%pi*x)/240)
-(%pi*x*cosh((%pi*x)/240))/240)*cos((%pi*y)/240))
/13-(25*x)/48$
Now in order to plot that, it should be a function of x and y only. However listofvars reports that it contains x, y, and p. Hmm. I see that βp has a summation over p1 but it contains Ζ0, which contains Λ0, which contains p. Is the summation over p1 supposed to be over p? Is the summand supposed to contain p1 instead of p?
Likewise it appears that N2, after evaluating the sums and integrals with j equal to 1, contains p.
Maybe you need to rework the formulas somewhat? I don't know what the correct form might be.
Does anyone know how to calculate a Mod b in Casio fx-991ES Calculator. Thanks
This calculator does not have any modulo function. However there is quite simple way how to compute modulo using display mode ab/c (instead of traditional d/c).
How to switch display mode to ab/c:
Go to settings (Shift + Mode).
Press arrow down (to view more settings).
Select ab/c (number 1).
Now do your calculation (in comp mode), like 50 / 3 and you will see 16 2/3, thus, mod is 2. Or try 54 / 7 which is 7 5/7 (mod is 5).
If you don't see any fraction then the mod is 0 like 50 / 5 = 10 (mod is 0).
The remainder fraction is shown in reduced form, so 60 / 8 will result in 7 1/2. Remainder is 1/2 which is 4/8 so mod is 4.
EDIT:
As #lawal correctly pointed out, this method is a little bit tricky for negative numbers because the sign of the result would be negative.
For example -121 / 26 = -4 17/26, thus, mod is -17 which is +9 in mod 26. Alternatively you can add the modulo base to the computation for negative numbers: -121 / 26 + 26 = 21 9/26 (mod is 9).
EDIT2: As #simpatico pointed out, this method will not work for numbers that are out of calculator's precision. If you want to compute say 200^5 mod 391 then some tricks from algebra are needed. For example, using rule
(A * B) mod C = ((A mod C) * B) mod C we can write:
200^5 mod 391 = (200^3 * 200^2) mod 391 = ((200^3 mod 391) * 200^2) mod 391 = 98
As far as I know, that calculator does not offer mod functions.
You can however computer it by hand in a fairly straightforward manner.
Ex.
(1)50 mod 3
(2)50/3 = 16.66666667
(3)16.66666667 - 16 = 0.66666667
(4)0.66666667 * 3 = 2
Therefore 50 mod 3 = 2
Things to Note:
On line 3, we got the "minus 16" by looking at the result from line (2) and ignoring everything after the decimal. The 3 in line (4) is the same 3 from line (1).
Hope that Helped.
Edit
As a result of some trials you may get x.99991 which you will then round up to the number x+1.
You need 10 ÷R 3 = 1
This will display both the reminder and the quoitent
÷R
There is a switch a^b/c
If you want to calculate
491 mod 12
then enter 491 press a^b/c then enter 12. Then you will get 40, 11, 12. Here the middle one will be the answer that is 11.
Similarly if you want to calculate 41 mod 12 then find 41 a^b/c 12. You will get 3, 5, 12 and the answer is 5 (the middle one). The mod is always the middle value.
You can calculate A mod B (for positive numbers) using this:
Pol( -Rec( 1/2πr , 2πr × A/B ) , Y ) ( πr - Y ) B
Then press [CALC], and enter your values for A and B, and any value for Y.
/ indicates using the fraction key, and r means radians ( [SHIFT] [Ans] [2] )
type normal division first and then type shift + S->d
Here's how I usually do it. For example, to calculate 1717 mod 2:
Take 1717 / 2. The answer is 858.5
Now take 858 and multiply it by the mod (2) to get 1716
Finally, subtract the original number (1717) minus the number you got from the previous step (1716) -- 1717-1716=1.
So 1717 mod 2 is 1.
To sum this up all you have to do is multiply the numbers before the decimal point with the mod then subtract it from the original number.
Note: Math error means a mod m = 0
It all falls back to the definition of modulus: It is the remainder, for example, 7 mod 3 = 1.
This because 7 = 3(2) + 1, in which 1 is the remainder.
To do this process on a simple calculator do the following:
Take the dividend (7) and divide by the divisor (3), note the answer and discard all the decimals -> example 7/3 = 2.3333333, only worry about the 2. Now multiply this number by the divisor (3) and subtract the resulting number from the original dividend.
so 2*3 = 6, and 7 - 6 = 1, thus 1 is 7mod3
Calculate x/y (your actual numbers here), and press a b/c key, which is 3rd one below Shift key.
Simply just divide the numbers, it gives yuh the decimal format and even the numerical format. using S<->D
For example: 11/3 gives you 3.666667 and 3 2/3 (Swap using S<->D).
Here the '2' from 2/3 is your mod value.
Similarly 18/6 gives you 14.833333 and 14 5/6 (Swap using S<->D).
Here the '5' from 5/6 is your mod value.